Reject root-run updates before changing user state

[yashranaway]

Catches updates run with sudo before user migrations start looking for configuration in root's home. Addresses #11257.

<<<< AI wording below >>>>

Problem

Running sudo omarchy update gives user-scoped migration steps root's home directory. Theme handover can then look for Hermes configuration under /root, fail, and leave a partially updated user setup.

Addresses the root-run update in #11257.

Fix

Reject effective UID 0 before opening the update log or running any update steps. Explain that the command must run as the desktop user and that individual steps request privileges when needed.

Verification

bash test/shell.d/update-root-test.sh covers both logged and initial root invocations and the normal-user logging path. The effective UID is substituted in a fixture copy so the test needs no root access. bash test/shell.d/update-sequence-test.sh and bash test/shell.d/update-lock-test.sh also pass.

git diff --check passes. Changed shell files pass bash -n, and the command style checks pass.

Fixes #13329

[greptile-apps]

Confidence Score: 5/5

[Medium risk] Adds a root-user check to the update script.

The PR appears safe to merge; no outstanding finding remains.

Summary

This PR rejects updates run with effective UID 0 before logging, locking, or update steps begin.

• Adds tests for root-run rejection and the normal-user entry path.

_{Reviews (4) · Last reviewed commit: "Merge remote-tracking branch 'origin/qua..."}

[omarchybot]

Reviewed and tested at b230fb0. The fix is right: sudo omarchy update runs per-user steps as root, which is what broke the Hermes theme handover in #11257 and left root-owned mise installs in #13329, and refusing root at the entry point is the proportionate fix. I found no legitimate root caller of bin/omarchy-update in the repository.

I pushed three commits to your branch so the fix holds on today's quattro:

• Merged quattro (f630b74). quattro has since hardened omarchy-update with a privileged Bash startup and a source-root check, so the guard had to be placed among those.
• Moved the guard ahead of omarchy_security_require_source_root (3720c93). Plain sudo resets the environment, so on a stock install root arrives without OMARCHY_PATH. After the merge, the source-root check exited first with "OMARCHY_PATH does not match this Omarchy command." instead of your message. A root run that got past that check still installed the cleanup traps and ran sudo -k before being refused. The guard now runs right after environment sanitising, before any of that.
• Rewrote test/shell.d/update-root-test.sh against the real script (0e537ac, b230fb0). A sed-edited copy run with plain bash is now refused by the startup check before it reaches the guard. The test now drives the real script through the sudo-boundary fixture and gets EUID 0 from an unprivileged user namespace. It covers root with and without OMARCHY_PATH and asserts that nothing is logged and sudo is never touched. When the suite itself runs as root, it skips the normal-user case, as the other root-aware tests do.

What ran, on a disposable Omarchy worker:

• The new test fails on quattro, passes at this head, and fails again with the guard removed. It also passes as a root runner.
• Real sudo ./bin/omarchy-update -y prints the refusal and exits 1, with or without OMARCHY_PATH, and no update log is written.
• These shell tests pass: update-sequence, update-user-path, security-source-root, security-entrypoint-symlink, update-disk-space, update-file-conflict, update-keyring, channel-sudo-boundary and runtime-smoke.
• ./test/cli gives the same result here as on quattro: 114 pass, and two vscode theme checks fail on quattro itself.

Codex Medium reviewed this as a second opinion over three rounds. It raised the unquoted string literal and the root-runner assumption fixed above; Greptile raised the root-runner case too. Its last round, at b230fb0, found nothing open.

Two other open pull requests make the same change: #13377 and #13660. Codex Medium compared all three without being given my answer and ranked this one first, though its independence from this session is not guaranteed. #13377 places its guard after the source-root check, so plain sudo still prints the OMARCHY_PATH error. #13660 places its guard after that check and after the sudo -k setup, and its test only greps for the guard's text. That choice is the maintainer's.

This now closes #13329. #11257 also reports that the failed migration's marker was still written, which this does not touch, so I have not linked it. This is waiting on the maintainer.

[yashranaway]

Checked the pushed root guard and current privileged startup boundary; the root-update regression passes after merging quattro.

[omarchybot]

The head moved from b230fb0 to c4a98a0, so the verified and ready labels came off; they describe a revision, not the pull request.

I read the new commits. c4a98a0 and e50c09f merge quattro (up to f45461a) into the reviewed head and carry nothing else: the merged tree is identical to a fresh merge of b230fb0 with f45461a, and the change this pull request makes to bin/omarchy-update and test/shell.d/update-root-test.sh is unchanged. The only update-path change quattro brought in is the Grok install in bin/omarchy-update-mise, which runs well after the root guard.

I did not re-run anything at this head, and its classification is unsettled. Every item needs a second opinion before it is re-verified or relabelled, and today's quota of reviewer calls is spent: Codex Medium answers, but omabot's daily cap on calls to it was reached before this item, so no second review ran. Nothing is needed from you. This waits for a run with a second opinion, which will re-verify this head on a worker.