Merge upstream sync b86d4505 (README resolved toward CN rewrite)

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QKxGW1raAWaqeU8WdHsMsp

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