assertNotRoot only checked process.getuid(), so the guard was bypassed
when the CLI was launched with a non-root real UID but an effective UID
of 0 (e.g. via a setuid-root wrapper). In that context the process still
has root write privileges and can cause the same state/config corruption
the guard was added to prevent.
Now checks both getuid() and geteuid() — either being 0 triggers the
guard. Added three tests covering setuid-root scenarios.
OPENCLAW_CLI_CONTAINER_BYPASS alone is an internal recursion sentinel,
not a user-facing opt-in. Require OPENCLAW_CONTAINER_HINT to also be
present — this combination only occurs in the container-forwarding flow
(container-target.ts), so inherited or accidental env vars can no
longer silently skip the root guard.
The container forwarder sets OPENCLAW_CLI_CONTAINER_BYPASS=1 but not
OPENCLAW_ALLOW_ROOT. When the child CLI inside a root-based container
hits assertNotRoot(), it would exit before command handling. Exempt
container-forwarded invocations from the root guard.
Block openclaw CLI from running as root (uid 0) to prevent:
- Separate state directory at /root/.openclaw/
- Conflicting systemd user services racing on port 18789
- Root-owned files in the service user state dir (EACCES)
The guard runs early in src/entry.ts before any state/config operations.
Root-level --help and --version bypass the guard so users can discover
the OPENCLAW_ALLOW_ROOT=1 override. Subcommand help paths still enforce
the guard since they enter runCli() and resolve state directories.
Closes#67478
