Codex CLI: Use OpenAI’s AI Coding Agent in the Linux Terminal

It’s easy to install an AI agent, run it with all the guardrails turned off, and only check the sandbox settings after it has changed a configuration file you needed. Codex provides three sandbox levels along with a separate approval policy. The combination you choose determines what it can access and modify.

So before getting into the useful stuff, we’ll install Codex, sign in, and then look closely at the flags that control what it can and cannot touch.

What Codex Does on a Linux Machine

Codex CLI is a local agent that works directly in your terminal. It can read your repository, suggest and make edits, run ls command, grep command, execute your test suite, and show you a diff of the changes it made.

For a sysadmin, that last part is especially important. Codex isn’t just a chat window that prints code for you to copy and paste; it can actually run commands in your shell and make changes on your system. That’s why the sandbox section below is worth reading carefully.

The examples in this guide were tested on Ubuntu 26.04 and RHEL 10. The commands should also work on any modern Linux distribution running on a 64-bit x86 or ARM system.

Install Codex CLI on Linux

The quickest way to install Codex CLI is with the official install script. It downloads a prebuilt binary and places it on your PATH.

curl -fsSL https://chatgpt.com/codex/install.sh | sh

Here’s what each part of the command does:

• curl downloads the install script over HTTPS.
• -f makes curl fail on server errors instead of saving an HTML error page.
• -s runs silently, while -S shows real error messages.
• -L follows redirects used by the download endpoint.
• | sh sends the downloaded script directly to the shell for execution.

That last part comes with an important warning. Piping a remote script directly into sh means the shell executes whatever the server sends. If you’re installing Codex on a system you don’t own or manage, download the script first, review it, and then run it:

curl -fsSL https://chatgpt.com/codex/install.sh -o codex-install.sh

Then inspect the script before executing it.

If you prefer using Node.js, install Node.js and npm first. The package manager command depends on your distribution, so use the one that matches your system.

On Ubuntu/Debian:

sudo apt install nodejs npm

On RHEL/Rocky Linux:

sudo dnf install nodejs npm

sudo runs the command with root privileges. You need it here because the package managers may need to write to system directories. Without it, you may see a Permission denied error.

Once Node.js and npm are installed, install Codex CLI globally:

npm install -g @openai/codex

There’s also a third option if you don’t want to use a package manager; the latest GitHub release provides static binaries. On a 64-bit Intel or AMD system, download codex-x86_64-unknown-linux-musl.tar.gz, extract it, rename the binary to codex, and move it to a directory in your PATH.

Whichever installation method you use, verify that Codex is available:

codex --version

If you see a version number instead of command not found, Codex is installed and available on your PATH. If it isn’t, check the troubleshooting section near the end of the guide. In most cases, the problem is simply that the directory containing the binary isn’t in your PATH.

Sign In From a Headless Server

The first time you run codex, it asks you to sign in. On a desktop, Codex opens your browser and completes the ChatGPT OAuth sign-in automatically.

On a server you connect to over SSH, there’s usually no browser available to open. This is where the device authentication flow comes in:

codex login --device-auth

Codex displays a short code and a URL. Open the URL on your laptop, enter the code, and the server completes authentication without needing to launch a browser locally.

Codex is included with ChatGPT Plus, Pro, Business, Edu, and Enterprise plans, so signing in with your ChatGPT account is the usual approach. If you’re using Codex in automation instead, you can provide an API key through an environment variable:

printenv OPENAI_API_KEY | codex login --with-api-key

You can check your authentication status at any time:

codex login status

This shows the active authentication method and exits with status 0 when valid credentials are available, making it useful as a simple check at the beginning of a shell script.

Sandbox Modes: The Setting That Actually Matters

Codex separates two questions that are easy to mix up: What can the agent access? And when should it stop and ask you?

The sandbox controls the first question with --sandbox, or -s for short:

• read-only lets Codex read files and run commands that don’t modify anything. Nothing on disk is changed.
• workspace-write lets Codex modify files inside the current working directory, but not elsewhere.
• danger-full-access removes the sandbox boundary completely and allows commands to access anything your user account can access.

The approval policy controls the second question with --ask-for-approval, or -a:

• untrusted pauses for commands Codex doesn’t already consider safe.
• on-request lets Codex ask when it needs to perform an action outside the sandbox.
• never runs the entire session without asking for approval.

For everyday work in a repository, the combination worth remembering is:

codex --sandbox workspace-write --ask-for-approval on-request

This gives Codex enough access to edit code and run tests without asking for approval every few seconds, while still keeping it inside the directory where you started it. If it needs to access something outside that directory, you get a chance to approve it.

If the task genuinely requires access to another directory, grant access to that directory explicitly instead of weakening the sandbox:

codex --sandbox workspace-write --add-dir /var/www/

Angle brackets such as <your-site> are placeholders used throughout this article. Replace them with your actual value and remove the brackets.

The Flag You Shouldn’t Reach For

Codex also has a --dangerously-bypass-approvals-and-sandbox flag, aliased as --yolo, which disables both approval prompts and sandboxing. The name is a pretty good warning.

The safest place to use this flag is inside a container or a throwaway VM that is already isolated at the operating-system level. On a machine containing real data, workspace-write with on-request gives you a good balance of speed and protection.

Slash Commands Worth Knowing

Once you’re inside the terminal UI, type / to open the command popup. These are the commands you’ll use most often:

• /status shows the active model, approval policy, writable roots, and how much context you have left.
• /diff shows the Git diff of everything Codex changed, including files that Git isn’t tracking yet.
• /review asks Codex to review your working tree and look for behavior changes or missing tests.
• /compact summarizes the conversation so far and frees up context during a long session.
• /permissions changes the approval preset without restarting Codex.
• /model switches the active model before you start a more demanding task.

Run /status as soon as you start a session. It’s the quickest way to confirm that Codex is using the sandbox you expect. It can also help catch situations where an existing ~/.codex/config.toml setting is overriding the flags you passed on the command line.

Running Codex Against a Local Model

If you want to keep your code and requests on your own hardware, --oss lets Codex use a local model provider instead of OpenAI’s hosted models:

codex --oss --local-provider ollama

This sends requests to Ollama running on the same machine. LM Studio is also supported with --local-provider lmstudio:

codex --oss --local-provider lmstudio

The trade-off is performance and capability. Local models may not perform as well as hosted models, especially on larger or more complex coding tasks, but they give you more control over where your code and requests are processed.

Run Codex Non-Interactively With codex exec

The terminal UI works well when you’re sitting at the keyboard. For cron jobs, CI pipelines, and other tasks that need to run without a person watching, use codex exec, which is also available as codex e.

codex exec --sandbox read-only -o /tmp/audit.md "Summarise every systemd unit in this repo that runs as root"

Here’s what each part does:

• codex exec runs a single task and exits instead of opening the terminal UI.
• --sandbox read-only prevents the run from making changes, which is what you want for an audit.
• -o /tmp/audit.md saves the final response to a file that you can review, email, or commit.
• The quoted string is the prompt. If you use - instead, Codex reads the prompt from standard input.

Two more options become useful when you put Codex into scripts. --json outputs newline-delimited JSON events instead of formatted text, making it easy to pipe the output into jq and use the results in your script. --skip-git-repo-check allows Codex to run in a directory that isn’t a Git repository, which it otherwise refuses to use.

If a scripted run stops partway through and you want to continue instead of starting again, use:

codex exec resume --last

This resumes the most recent session from the current directory.

Tell Codex Your Rules With AGENTS.md

Codex reads an AGENTS.md file from the directory where it is working and uses it as a set of standing instructions. You can create a starter file from inside a Codex session with:

/init

This creates a basic scaffold in the current directory. Edit it to include the rules that matter for your project, such as which test command to run, which directories are generated and should not be edited manually, and any deployment step that Codex must never run automatically.

Once you’re happy with the instructions, commit the AGENTS.md file to your repository. That way, you don’t have to explain the same project conventions at the start of every session.

When Codex Won’t Start

The most common problem immediately after installation is a shell that can’t find the codex command.

codex: command not found

Both the install script and npm install -g place the codex binary in a directory that your current shell may not have picked up yet. Start by opening a new shell and try again. If the command still isn’t found, check where npm installs global binaries:

npm config get prefix

Then add the corresponding bin directory to your PATH in ~/.bashrc. Reload the shell and run:

codex --version

If it prints the version, your PATH is configured correctly.

Everything Else

Codex includes its own diagnostic command, which checks your installation, configuration, authentication, runtime, Git, and terminal setup in one pass:

codex doctor --summary

The --summary flag shows grouped check results and a final count instead of the full diagnostic report. That’s usually enough to quickly identify what’s wrong. When you need more detail, run the command without --summary. If you’re attaching the output to a bug report, add –-json; the JSON output is redacted.

There’s also a version-related detail worth knowing. The old --full-auto flag is deprecated and displays a warning, so use --sandbox workspace-write instead. Likewise, codex mcp-server has been replaced by the Codex app server.

Conclusion

You’ve now installed codex using a script, npm package, or static binary, signed in from a headless server with the device code flow, and learned how --sandbox and --ask-for-approval control what the agent can access and when it needs your approval.

You’ve also seen how codex exec lets you run tasks without the interactive terminal UI, making it useful for scripts and automation. Here’s a good way to start. Pick a repository you know well, run:

codex --sandbox read-only

Then ask Codex to explain a file you’re already familiar with. Because the session is read-only, it can’t modify anything. You can evaluate the quality of its answers before giving it permission to make changes.

What’s the first task you’d trust Codex with on a real server, and what’s the one you wouldn’t? Share it in the comments. The boundaries people set around these tools can be just as interesting as the tools themselves.