CVE-2025-61260: Secure Codex CLI Fast

Short answer

CVE-2025-61260 is an OpenAI Codex CLI vulnerability that can allow a poisoned repository to trigger attacker-chosen commands when Codex starts. Update to Codex CLI 0.23.0 or later, and use safer sandbox and ask-for-approval settings, especially in untrusted repos and CI. Treat project folders like inputs, not trusted configuration sources.

You can think of it like a toolbox that auto-loads tools from a project folder. If a malicious project places a dangerous tool in that folder, Codex may pick it up unless you lock it down.

Quick check: are you running Codex CLI 0.23.0 or later?

What is CVE-2025-61260?

CVE-2025-61260 is a Codex CLI command-injection issue caused by overly trusting project-local settings. An attacker can add files to a repo so that when you run Codex, it may start an MCP server entry that includes a command. This can lead to remote code execution on the machine running Codex.

A common reported pattern is a repo including a .env file that changes where Codex looks for config (via CODEX_HOME), plus a project-local config such as .codex/config.toml with risky entries. If those entries are invoked without clear confirmation, startup can become code execution.

Who is affected?

You’re most at risk if you:

• Run Codex CLI inside repos you didn’t create (templates, forks, new open-source projects).
• Allow broad permissions (write access, command execution, or network access) without tight approvals.
• Run Codex in automation (CI/CD) on checked-out code.

This is a software supply chain security risk. A single poisoned commit can impact many downstream users.

What should I do first? (10-minute hardening checklist)

1. Check your version and upgrade if needed. Use Codex CLI 0.23.0 or later.

   codex --version

2. Decide trust before you run Codex in a repo. If it’s new, from the internet, or from a fresh pull request, treat it as untrusted.
3. Use safer flags in untrusted repos (see the table below). Start in read-only if you’re unsure.
4. Lock down CI: prefer read-only, non-interactive mode and avoid surprise command execution.
5. Scan for repo-local Codex config before running. Look for .env, CODEX_HOME, and .codex/config.toml.
6. If you already ran Codex in a suspicious repo, follow the incident steps later in this guide.

How does the attack work (high level)?

Here’s a safe, big-picture flow (no exploit details):

• A repo contains a .env file that points Codex to a project-local config folder (for example, by setting CODEX_HOME).
• The repo includes a local config file (often .codex/config.toml) that defines MCP server entries.
• When Codex starts, it reads that config and may automatically run the MCP server command.

The key problem is implicit trust. A normal workflow (clone repo, run Codex) can become command execution.

How to run Codex CLI safely in untrusted repos

Use a least-privilege mindset: give Codex the smallest set of powers it needs. For untrusted repos, start in read-only. If you need edits, keep approvals strict.

Situation	Recommended mode	Why it helps
Inspecting a new or untrusted repo	--sandbox read-only --ask-for-approval on-request	Codex can read, but can’t edit or run commands without prompts.
Edits needed, but no surprise commands	--sandbox workspace-write --ask-for-approval untrusted	Edits are allowed, but command runs get extra scrutiny.
Trusted repo, day-to-day work	Use your org baseline; keep approvals on for risky actions	Reduces chances of accidental side effects.

Network access note: keep network access disabled unless you truly need it. If you enabled network access in config, review it and turn it off for untrusted work.

How to secure Codex in CI (non-interactive mode)

CI/CD is where supply chain problems can spread quickly. The safest approach is read-only and non-interactive, so the tool behaves like an auditor rather than an operator.

Recommended CI baseline:

• Use read-only sandboxing.
• Use never ask-for-approval, because CI can’t respond to prompts.
• Disable network access unless you have a strict allow list and strong justification.

codex --sandbox read-only --ask-for-approval never

If your pipeline runs Codex with write permissions or broad command execution, treat that as high risk and change it.

How to audit a repo for risky Codex settings

Before running Codex in a repo you don’t fully trust, check for files that change how Codex loads config and MCP servers. Review changes in pull requests carefully, especially any new configuration files.

What to look for	Why it matters	Simple check
.env files	May set CODEX_HOME or other behavior-changing variables	git ls-files | grep -E "(^|/)\.env$"
CODEX_HOME	Can redirect Codex config path into the repo	git grep -n "CODEX_HOME"
.codex/config.toml	Can define MCP server entries (commands/args)	git ls-files | grep -E "(^|/)\.codex/config\.toml$"
Unexpected new config files in a PR	PR-based config injection is a common pattern	Review the diff; block until explained

If you maintain templates or starter repos, consider adding a note: “Do not add project-local Codex config without review.” This reduces repository poisoning risk.

What to do if you already ran Codex in a suspicious repo

Handle it like a standard security incident: contain, check, rotate, and document. Move quickly if you suspect secrets or credentials could have been exposed.

1. Stop running Codex in that repo and close the terminal session.
2. Disconnect from sensitive networks if you suspect active compromise (for example, VPN or production access).
3. Rotate secrets that could be exposed (API keys, tokens, SSH keys, cloud credentials).
4. Check for unusual changes on your machine: new files, scheduled tasks, shell profile changes, or unexpected background processes.
5. Review logs: terminal logs, shell history, and any EDR alerts if your org has them.
6. Tell your team (AppSec/DevOps). If this came from a shared repo, others may be at risk too.

Consider a simple policy: Codex runs only in trusted repos by default, and untrusted repos must be read-only. This is least-privilege developer tooling in practice.

FAQ

Is this only a developer laptop problem?

No. It can impact laptops and CI/CD. If a build agent runs Codex on checked-out code, a poisoned repo can affect build steps and downstream artifacts.

What versions are fixed?

Public reporting indicates the fix shipped in Codex CLI 0.23.0. For best results, upgrade to the newest available version and review the release notes.

What settings matter most?

Start with sandboxing and approvals. Use sandbox mode plus ask-for-approval, and default to read-only for new repos. Loosen permissions only after you trust the repo.

What’s the main takeaway?

Tools that can run code must treat repos like inputs, not truths. Patch quickly, run read-only in untrusted repos, and keep CI locked down.

Checkpoint question: do you have a clear rule for trusted vs. untrusted repos on your team, and do your Codex flags match that rule?