OpenAI’s Codex CLI is the company’s terminal coding agent. It reads files, runs commands, and edits your repository. It is fast, it understands a large context window, and it can be wrong about which commands are safe to run without asking. The order in which you configure it matters far more than the order in which the install guide lists the steps.
The Tecmint walkthrough (the source this article was built from) goes install, sign in, sandbox, then a long list of slash commands. That order is fine for a demo. For a real server, the order should be sandbox first, install second, then sign in last. Most of the damage a coding agent can do on a Linux box happens in the first five minutes after you let it run on something you care about, before you have decided what boundaries you actually wanted.
What Codex is actually doing on your machine
Codex runs as a local binary. It uses your shell to read files in the current directory, run tests, and apply edits. The default config lets it modify anything your user account can modify. That includes your shell’s ~/.bashrc, your SSH keys, your cloud config, and any directory you happen to be sitting in when you launch it.
This is the part that is easy to forget when reading the marketing. Codex is not a chat window that prints code. It can run rm -rf on whatever you have access to. The sandbox flags exist exactly because of this. The question is not whether you trust the model. The question is whether you trust the model plus whatever bug it might have at 2am when you are not paying attention.
The good news is that the boundaries are configurable and defaults are sane. The bad news is that the defaults are sane for an interactive user, not for a server, and the server case is the one most sysadmins end up in.
The two questions, separated
Codex splits permission management into two layers. The first layer answers “what can the agent access?” The second answers “when should it stop and ask you?” These are different questions, and they are configured by different flags. Mixing them up is the most common mistake when reading the Codex documentation for the first time.
The access layer has three settings, in order of how much they let Codex do. The first lets it read files and run commands that do not modify anything. Nothing on disk is changed. The second lets it modify files inside the current working directory, but not elsewhere. The third removes the boundary entirely and lets Codex touch anything your user account can touch. The names of these modes are descriptive: read-only, workspace-write, and danger-full-access. The dangerous one is named for what it does.
The approval layer is separate. There are three policies, and they determine when Codex pauses for human input. The strictest pauses for anything Codex does not already consider safe. The middle setting lets Codex ask when it wants to do something outside the sandbox. The lax setting runs the entire session without asking. The names are untrusted, on-request, and never.
For everyday work in a repository, the combination to set first is workspace-write plus on-request. That gives Codex enough access to make code edits and run tests without an approval prompt every few seconds, while still keeping it inside the directory where you launched it. If it needs to do something outside that directory, you get a chance to approve it.
There is also a fourth flag, which is essentially “turn all the safety off at once.” Its full name reads like a warning label because it is one. The only safe place to use it is inside a sandbox already walled off at the operating-system level, like a disposable container or a throwaway VM. On a real machine, workspace-write with on-request gives a better balance of speed and protection.
Sign-in on a headless server
The first time you launch the binary, it asks you to sign in. On a desktop, Codex opens your browser and walks you through the standard ChatGPT login. On a server you reach over SSH, there is no browser available. The right command there is the device-auth flow: Codex prints a short code and a URL, you open the URL on your laptop, type the code, and the server completes authentication without ever needing a local browser.
If you are running Codex inside automation rather than interactively, the better path is to provide an API key through an environment variable. Either method works, and the choice is mostly about whether you can attach a browser to the box where Codex runs. The API key path is the right shape for any non-interactive use case: CI, cron jobs, pipelines. You can check which method is active at any time with the login-status subcommand, which is also useful as a check at the top of a shell script.
Install with the install script, but inspect it first
The fastest install path is the official install script. That command downloads a prebuilt binary and places it on your PATH. It is the right call on a personal laptop.
On a server, the right move is to download the script first, look at it, and then run it. Piping a remote script directly into sh means the shell executes whatever the server sends, with no opportunity to read it first. If you are installing Codex on a system you do not own or manage, do not pipe.
If you prefer Node.js, install Node and npm first, then install the npm package globally. If you prefer no package manager at all, the GitHub release page ships static binaries for both x86_64 and ARM. Whichever path you take, verify the install by asking the binary for its version. If you see a version number, the binary is on your PATH and reachable. If you see command not found instead, the most common cause is that the install path is not in your current shell’s PATH yet. Open a new shell, or add the install directory to ~/.bashrc.
Set rules with AGENTS.md before the first real task
Codex reads a file called AGENTS.md from the directory where it is working and treats the contents as standing instructions for the session. You can generate a starter file from inside a running Codex session with the /init slash command. Edit the starter to include what your project actually needs:
- Which test command should Codex run before claiming a task is done.
- Which directories are generated artifacts and should not be edited by hand (build outputs, vendored dependencies, lockfiles).
- Which deployment step Codex must never run automatically.
- Which commands are explicitly off-limits, even when the sandbox would allow them.
Once the file is in shape, commit it to your repository. That way, you do not have to repeat the same project rules every time a fresh Codex session begins. Codex reads the file at session start and re-reads it after every context-compaction event.
Trade-offs
Codex is a useful tool and a sharp one. The reason to set sandbox flags before you let it near a real box is not paranoia. It is the same reason you would not hand a new contractor the keys to your office on day one. The sandbox is cheap to configure and expensive to skip.
The cost of being careful is roughly one minute at install time and a few lines in AGENTS.md. The cost of skipping it is the time it takes to recover from a single bad edit on a directory that contained something you actually needed.
A practical order for a first-time install on a Linux box: download the install script and read it; install Codex; sign in with device-auth or API key; set the default sandbox to workspace-write; set the default approval to on-request; write an AGENTS.md that captures your project’s rules; then point Codex at your first real task. That sequence takes longer than the demo path but ends with a configuration you can leave unattended.