still enforces no_new_privs when run via systemd

Summary

When Codex CLI runs under a long-lived systemd service, commands still execute with PR_SET_NO_NEW_PRIVS even if we pass --dangerously-bypass-approvals-and-sandbox --platform-sandbox none. That blocks sudo/systemctl/loopback curls and defeats the point of opting into danger mode.

Environment

• codex-cli 0.73.0 (Node 22.21.1)
• Amazon Linux 2023 (kernel 6.1.158-180.294.amzn2023.x86_64)
• Service user ec2-user (passwordless sudo)
• systemd unit:

``ini
[Service]
Type=simple
User=ec2-user
WorkingDirectory=/home/ec2-user/co-deworker
EnvironmentFile=/etc/sandy-bridge.env
Environment=PATH=/home/ec2-user/.nvm/versions/node/v22.21.1/bin:/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin
ExecStart=/home/ec2-user/co-deworker/.venv/bin/python jvs/tools/bridge_client.py
Restart=always
``

• /etc/sandy-bridge.env includes:

``ini
BRIDGE_CODEX_FLAGS="--dangerously-bypass-approvals-and-sandbox --skip-git-repo-check --platform-sandbox none"
CODEX_ALLOW_DANGER=1
CODEX_PLATFORM_SANDBOX=none
``

Steps to reproduce

1. Run the above service (it shells out to codex exec --json ... with the flags from BRIDGE_CODEX_FLAGS).
2. Send any prompt that causes Codex to execute sudo or curl 127.0.0.1:5103/healthz (e.g., "run sudo systemctl is-active trading-preplays.service and report the result").

Expected result

Danger mode should disable both approvals and the platform sandbox. The agent should run privileged commands exactly like when I run CODEX_API_KEY=... codex exec --dangerously-bypass-approvals-and-sandbox --skip-git-repo-check --platform-sandbox none -- "run sudo whoami" manually (that prints root).

Actual result

Every command fails immediately with the kernel guard still enabled:

sudo: The "no new privileges" flag is set, which prevents sudo from running as root.
sudo: If sudo is running in a container, you may need to adjust the container configuration to disable the flag.

Loopback curl also fails with exit code 7, as if network isolation is still on. Here is the JSONL emitted by the non-interactive run when the service asks Codex to run sudo systemctl is-active trading-preplays.service and curl -s 127.0.0.1:5103/healthz:

{"type":"item.completed","item":{"command":"/bin/bash -lc 'cd /home/ec2-user/co-deworker && sudo systemctl is-active trading-preplays.service'","aggregated_output":"sudo: The \"no new privileges\" flag is set, which prevents sudo from running as root.\nsudo: If sudo is running in a container, you may need to adjust the container configuration to disable the flag.\n","exit_code":1,"status":"failed"}}
{"type":"item.completed","item":{"command":"/bin/bash -lc 'cd /home/ec2-user/co-deworker && curl -s 127.0.0.1:5103/healthz'","aggregated_output":"","exit_code":7,"status":"failed"}}

systemctl show bridge-client.service confirms NoNewPrivileges=no, so systemd is not forcing the flag. The flag only appears when Codex is launched from the service.

Additional notes

• The same CLI command succeeds when run manually in the exact same workdir/user, so this appears specific to the non-interactive/systemd path.
• This blocks our ACN bridge bots from running health checks (sudo systemctl ..., curl 127.0.0.1:5103/healthz) even though we've explicitly opted into danger mode.
• Please let me know if there’s another flag we should pass, or if the CLI could skip setting no_new_privs when --dangerously-bypass-approvals-and-sandbox is present.