Offer to reboot when toggling sudoless Docker; show only the relevant menu entry (backport of #8098)

Backport of the sudoless Docker follow-up (PR #8098, merged to quattro as
06a3dbca) onto the v4-0-1 release branch, on top of the #8056 and #8080
backports it follows.

Group membership only takes effect on a fresh session, and in practice a logout
or newgrp is not enough -- only a reboot reliably applies it. The setup and
remove commands now flag the reboot and offer to do it right away with a gum
confirm, the same shape as the GPU toggle, and their notices say "after a
reboot" instead of pointing at logout or newgrp. The existing-user migration
reuses the removal command inside omarchy update, so it passes
OMARCHY_DEFER_REBOOT to skip the prompt there and lets omarchy-update-restart
handle the reboot once the whole update has finished.

Setup > Security showed Sudoless Docker under both Setup and Remove, and the
guards tested the running session's groups, which do not change until the
reboot: after enabling sudoless Docker the menu still offered Setup, the one
action that could no longer do anything, while Remove stayed hidden. Add
omarchy-sudo-docker as the single answer to both questions that differ in that
window -- by default whether this session can reach the socket, which is what
decides if a command must elevate, and with --configured whether the account is
set up for it, which is what the menu and the toggles need. It succeeds when
sudo is needed, so the Setup entry appears while sudoless Docker is off and
Remove once it is on. lazydocker and the Windows VM keep prompting until the
reboot lands.

Clean cherry-pick on top of the earlier backports: every file is byte-identical
to quattro except default/omarchy/omarchy-menu.jsonc, which merged into this
branch's menu and whose two Sudoless Docker lines match quattro exactly.
test/shell passes: 188 files, including the two this adds. test/cli passes, so
the new command's metadata is well-formed. Exercised the helper here: with no
socket it reports sudo is needed, and --configured answers from the account's
groups.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018DEMYa9UWtroz93DhMTtcV

bin/omarchy-launch-docker-tui

@@ -9,10 +9,12 @@
 # no prompt. lazydocker needs the root-owned Docker socket, so when the group is
 # absent, gate that access behind a polkit prompt. If the user has opted into
 # sudoless Docker (omarchy-setup-security-sudoless-docker), the socket is already
-# reachable, so run lazydocker directly. pkexec sanitizes the environment, so
-# carry TERM through for the TUI to render and run lazydocker from root's PATH.
-if id -nG 2>/dev/null | grep -qw docker; then
-  exec lazydocker
-else
+# reachable, so run lazydocker directly — omarchy-sudo-docker answers that for
+# this session, so the prompt stays until the reboot that grants the group.
+# pkexec sanitizes the environment, so carry TERM through for the TUI to render
+# and run lazydocker from root's PATH.
+if omarchy-sudo-docker; then
   exec pkexec /usr/bin/env TERM="${TERM:-xterm-256color}" lazydocker
+else
+  exec lazydocker
 fi

bin/omarchy-remove-security-sudoless-docker

@@ -5,7 +5,10 @@
 
 set -e
 
-if ! id -nG "$USER" 2>/dev/null | grep -qw docker; then
+# Ask about the configured groups, not this session's: right after enabling,
+# sudoless Docker is on for the account even though the running session still
+# needs a prompt, and this command is what turns it back off.
+if omarchy-sudo-docker --configured; then
   echo "Sudoless Docker is not enabled: $USER is not in the docker group."
   exit 0
 fi
@@ -13,13 +16,19 @@ fi
 echo "Removing $USER from the docker group..."
 sudo gpasswd -d "$USER" docker >/dev/null
 
-# Group membership is fixed at login, so the running session keeps its docker
-# access until it ends. Flag a reboot so omarchy-update-restart prompts for one
-# (and the bar shows it pending); a plain log out and back in works too.
+# Group membership is only re-read by a fresh session, and in practice logging
+# out or newgrp isn't enough — only a reboot reliably applies it. Record it so a
+# later `omarchy update` still prompts (omarchy-update-restart reads this), then
+# offer to do it now.
 omarchy-state set reboot-required
 
 echo ""
-echo "Sudoless Docker DISABLED. Reboot (or log out and back in) for the change to take effect."
-echo "Docker access now goes through a polkit/sudo prompt again: the Docker TUI"
-echo "(Super + Shift + D) and the Windows VM will ask when they need it, and the"
-echo "plain 'docker' CLI runs under sudo."
+echo "Sudoless Docker DISABLED. Docker access goes through a polkit/sudo prompt"
+echo "again: the Docker TUI (Super + Shift + D) and the Windows VM ask when they"
+echo "need it, and the plain 'docker' CLI runs under sudo. It takes effect after a reboot."
+echo ""
+# The migration reuses this command during 'omarchy update' and defers the
+# reboot to omarchy-update-restart, so it doesn't cut the update short.
+if [[ -z ${OMARCHY_DEFER_REBOOT:-} ]] && gum confirm "Reboot now to apply?"; then
+  omarchy-system-reboot
+fi

bin/omarchy-setup-security-sudoless-docker

@@ -5,7 +5,9 @@
 
 set -e
 
-if id -nG "$USER" 2>/dev/null | grep -qw docker; then
+# Ask about the configured groups, not this session's: once enabled it stays
+# enabled for the account even before the reboot that lets this session use it.
+if ! omarchy-sudo-docker --configured; then
   echo "Sudoless Docker is already enabled: $USER is in the docker group."
   echo "To disable it again, run: omarchy-remove-security-sudoless-docker"
   exit 0
@@ -28,14 +30,20 @@ echo ""
 
 if gum confirm "Enable sudoless Docker? This gives anything running as you passwordless root."; then
   sudo usermod -aG docker "$USER"
-  # Group membership is fixed at login, so docker won't be reachable without a
-  # prompt until the session restarts. Flag a reboot so omarchy-update-restart
-  # prompts for one (and the bar shows it pending).
+  # A new docker group membership is only picked up by a fresh session, and in
+  # practice logging out or newgrp isn't enough — only a reboot reliably applies
+  # it. Record it so a later `omarchy update` still prompts
+  # (omarchy-update-restart reads this), then offer to do it now.
   omarchy-state set reboot-required
   echo ""
-  echo "Sudoless Docker ENABLED. Reboot, or log out and back in (or run 'newgrp docker'),"
-  echo "for the new group membership to take effect."
-  echo "To disable it again, run: omarchy-remove-security-sudoless-docker"
+  echo "Sudoless Docker ENABLED. It takes effect after a reboot."
+  echo "To disable it again: Setup > Security > Sudoless Docker."
+  echo ""
+  # The migration reuses this command during 'omarchy update' and defers the
+  # reboot to omarchy-update-restart, so it doesn't cut the update short.
+  if [[ -z ${OMARCHY_DEFER_REBOOT:-} ]] && gum confirm "Reboot now to apply?"; then
+    omarchy-system-reboot
+  fi
 else
   echo "Aborted. No changes made. Docker access still goes through a prompt."
 fi

bin/omarchy-sudo-docker

@@ -0,0 +1,44 @@
+#!/bin/bash
+
+# omarchy:summary=Succeed when Docker needs sudo, fail when it can be used directly
+# omarchy:args=[--configured]
+# omarchy:examples=omarchy-sudo-docker && echo "needs sudo" | omarchy-sudo-docker --configured
+# omarchy:hidden=true
+
+# The docker group is root-equivalent, so Omarchy leaves users out of it by
+# default and reaches the daemon through a prompt instead. Everything that has
+# to make that choice asks here rather than testing group membership itself.
+#
+# Two questions, because they have different answers between toggling sudoless
+# Docker and the reboot that applies it (group membership is fixed when the
+# session is created):
+#
+#   (default)      Does Docker need sudo *right now*? Answered by whether this
+#                  process can actually reach the socket, which is what decides
+#                  if a command must elevate. Still true in the window after
+#                  sudoless Docker is enabled but before the reboot.
+#   --configured   Will it need sudo once the account's groups take effect?
+#                  Answered from the account's configured groups, so the menu
+#                  offers the toggle that can actually change state.
+#
+# Succeeds (exit 0) when sudo is needed, so it reads as `if omarchy-sudo-docker`.
+
+DOCKER_SOCKET="${OMARCHY_DOCKER_SOCKET:-/var/run/docker.sock}"
+
+case "${1:-}" in
+--configured)
+  # An account in the docker group will not need sudo after the next login.
+  id -nG "$USER" 2>/dev/null | grep -qw docker && exit 1
+  exit 0
+  ;;
+"")
+  # A socket we can write is a daemon we can drive without elevating. A missing
+  # socket counts as needing sudo: reaching it means starting it as root anyway.
+  [[ -w $DOCKER_SOCKET ]] && exit 1
+  exit 0
+  ;;
+*)
+  echo "Usage: omarchy-sudo-docker [--configured]" >&2
+  exit 2
+  ;;
+esac

bin/omarchy-windows-vm

@@ -31,8 +31,11 @@ CONTAINER="omarchy-windows"
 
 # --- privilege helpers -------------------------------------------------------
 
-# True when the user can reach the Docker socket directly (sudoless Docker on).
-in_docker_group() { id -nG 2>/dev/null | grep -qw docker; }
+# True when this session can reach the Docker socket directly (sudoless Docker
+# on and in effect). Asking about the socket rather than the configured groups
+# keeps the prompt in place through the window where sudoless Docker is enabled
+# but the reboot that grants the group has not happened yet.
+docker_needs_sudo() { omarchy-sudo-docker; }
 
 # The command to hand pkexec for the privileged re-exec. pkexec runs whatever
 # executable it is given (after authorization) and only shows the path in the
@@ -64,7 +67,7 @@ priv_target() {
 priv() {
   local action="$1"
   shift
-  if [[ $action != write_compose ]] && in_docker_group; then
+  if [[ $action != write_compose ]] && ! docker_needs_sudo; then
     "__priv_$action" "$@"
     return
   fi