CODEX(7) Savvy Admin Process Reference CODEX(7)

NAME

codex — OpenAI's Codex CLI agent: a native binary that edits files and runs commands in your repository under two settings, the sandbox mode that the operating system enforces and the approval policy that decides when it asks you.

kind: ai agent · package: @openai/codex (npm); the platform binary ships in @openai/codex-linux-x64 · binary: codex — bin/codex.js is a small Node launcher that execs the native, statically linked binary at node_modules/@openai/codex-linux-x64/vendor/x86_64-unknown-linux-musl/bin/codex, so the running process is codex, not node · config: ~/.codex/config.toml, .codex/config.toml (project; loaded only once the directory is trusted), requirements.toml (admin-enforced limits), ~/.codex/ (cached credentials, logs, sessions) · updated 2026-10-20

docs last verified 2026-10-20 — 0 days ago

SAFE TO KILL?

VERDICTYES. An ordinary user process: Ctrl-C or kill -TERM stops it, and at worst leaves a half-applied edit or a child command still running. Check git status and git diff, then ps for leftover children. Killing it does not undo anything a bypassed sandbox already allowed.

SYMPTOMS

· a codex process at high CPU for minutes: the build or test run it launched, look at its children
· commands it runs fail with permission denied or cannot reach the network: the workspace-write sandbox doing its job
· writes outside the repository: danger-full-access, or a session started with --dangerously-bypass-approvals-and-sandbox

WHAT IT CAN DO

Two knobs. sandbox_mode (-s / --sandbox): read-only reads the workspace and nothing else; workspace-write may also write inside the workspace (plus writable_roots) and has no network unless sandbox_workspace_write.network_access is true; danger-full-access turns the OS sandbox off. approval_policy (-a / --ask-for-approval, interactive sessions): on-request lets the model decide when to ask you, never returns failures to the model without asking; the current config reference marks untrusted unsupported and on-failure deprecated. --dangerously-bypass-approvals-and-sandbox switches both off at once. Enforcement is Landlock plus seccomp on Linux (bubblewrap when enabled), Seatbelt on macOS, a restricted token on Windows. A project's own .codex/config.toml, hooks and rules load only after you mark the directory trusted (projects."<path>".trust_level = "trusted"); requirements.toml lets an administrator pin settings users cannot loosen.

DIAGNOSE

$ ps -eo pid,user,etime,args | grep -w '[c]odex' who runs it and with which flags; -s, -a or --dangerously-bypass-approvals-and-sandbox on the command line override the config file$ ps --ppid "$(pgrep -x codex | head -1)" -o pid,etime,args its children are what it is executing right now$ grep -E '^(sandbox_mode|approval_policy|model|trust_level)|^\[sandbox_workspace_write\]|network_access|writable_roots' ~/.codex/config.toml .codex/config.toml 2>/dev/null the effective policy and which projects are trusted; a network_access = true under [sandbox_workspace_write] is the line to look for$ find ~/.codex -maxdepth 1 -type f -perm /077 -printf '%m %p\n' ~/.codex holds cached credentials when cli_auth_credentials_store is file (the alternatives are keyring, auto and ephemeral); nothing in it should be readable by other users

HARDEN

1. Leave read-only as the default and open up per session. read-only is the default sandbox. Grant workspace-write for the sessions that must edit, and keep network_access off in [sandbox_workspace_write] so a prompt-injected command cannot exfiltrate anything.

$ codex -s workspace-write

2. Pin what users may not loosen. requirements.toml, deployed by an administrator, constrains security-sensitive settings; omitted keys stay unconstrained. allow_managed_hooks_only = true there makes Codex ignore user, project and session hooks.

3. Use the bypass only where the container is the boundary. --dangerously-bypass-approvals-and-sandbox (or sandbox_mode = "danger-full-access") is the documented way to run inside a container that lacks Landlock or seccomp; outside a container it means the model's commands run with your full account.

4. Do not trust a directory you did not write. trust_level = "trusted" lets the repository's .codex/ layer configure the agent (config, hooks, rules). Clone third-party repositories as untrusted, or into a throwaway user or container.

5. One Unix user per agent. The sandbox limits the commands, not the account: anything the sandbox lets through runs as you. A dedicated account keeps your ssh keys and shell history out of reach.

IMPOSTORS

$ readlink /proc/$(pgrep -x codex | head -1)/exe a real one resolves to .../@openai/codex-linux-x64/vendor/x86_64-unknown-linux-musl/bin/codex under your npm prefix (or wherever you installed the release binary); anything under /tmp, /dev/shm or an unexpected dot-directory is not Codex$ codex --version prints codex-cli and a version; a miner wearing the name has no such answer

DISTRIBUTIONS

any npm install -g @openai/codex pulls the matching @openai/codex-<os>-<arch> package with the static binary; Landlock needs a kernel of 5.13 or later. Inside a container without Landlock or seccomp, the sandbox cannot start and the documented fallback is danger-full-access with the container as the boundary.

APPLIES TO

Codex CLI 0.16x (checked against the config reference and codex --help on 2026-10-20). Flag names and policy values have already changed once (untrusted, on-failure) and will again; see the verified date.

SOURCES

1. Codex docs — Config reference (approval_policy, sandbox_mode, sandbox_workspace_write, projects.trust_level), fetched 2026-10-20
2. Codex docs — CLI overview, fetched 2026-10-20
3. openai/codex repository docs — codex sandbox (mirror), fetched 2026-10-20
Machine-readable: /process/codex.json · changelog 2026-10-20: first version; -a/--ask-for-approval is accepted by the interactive command, not by codex exec, and --full-auto no longer appears in --help

Ubuntu 26.04 · codex-cli 0.163.0 via npm (binary location, flags, --help text); docs read 2026-10-20 2026-10-20 CODEX(7)