OpenAI Codex CLI is a command-line tool that integrates AI-assisted code reasoning into developer workflows, allowing natural language interaction with code projects. A critical feature, the Model Context Protocol (MCP), enables integration of external tools via project-local configuration files. The vulnerability arises because Codex CLI automatically loads and executes MCP server commands defined in project-local configuration files (.env and ./.codex/config.toml) without any interactive approval, validation, or re-checks upon changes. Specifically, if a repository contains a .env file setting CODEX_HOME to a local directory and a corresponding config.toml with mcp_servers entries, Codex CLI treats these as trusted execution material and runs the declared commands at startup. An attacker who can commit or merge such files can inject arbitrary commands that execute silently on any developer’s machine when Codex runs, including reverse shells or payloads that exfiltrate credentials. This creates a stealthy supply-chain backdoor that persists and can be swapped post-merge without triggering alerts. The vulnerability breaks the expected security boundary by implicitly trusting project-supplied files, enabling attackers to compromise developer environments, CI pipelines, and downstream build artifacts. Check Point Research disclosed the issue to OpenAI on August 7, 2025, and a fix was released on August 20, 2025, in Codex CLI version 0.23.0. The patch prevents .env files from redirecting CODEX_HOME to project directories, stopping automatic execution of attacker-controlled commands. Users are strongly advised to update to this version or later to mitigate the risk.

For European organizations, this vulnerability poses significant risks especially for software development teams using OpenAI Codex CLI in collaborative environments. Attackers with repository write access can embed malicious commands that execute on developer machines without detection, leading to credential theft (including cloud tokens and SSH keys), persistent remote access, and lateral movement within corporate networks. Supply-chain attacks can propagate through compromised open-source projects or internal templates, affecting multiple organizations downstream. CI/CD pipelines that run Codex CLI on checked-out code are also at risk, potentially contaminating build artifacts and production deployments. The silent and automatic nature of the execution increases the likelihood of unnoticed compromise, threatening confidentiality, integrity, and availability of development environments and associated infrastructure. This can result in intellectual property theft, disruption of software delivery, and exposure of sensitive data. The vulnerability’s exploitation requires no user interaction beyond normal developer workflows, amplifying its impact. European organizations with extensive software development operations, especially those in technology, finance, and critical infrastructure sectors, face elevated risks.

1. Immediately update all OpenAI Codex CLI installations to version 0.23.0 or later, which includes the fix preventing project-local CODEX_HOME redirection and automatic execution of MCP server commands from untrusted locations. 2. Audit all repositories for the presence of .env files setting CODEX_HOME and ./.codex/config.toml files containing mcp_servers entries; remove or sanitize any suspicious or unnecessary configurations. 3. Implement strict repository access controls and code review policies to prevent unauthorized commits or merges that could introduce malicious project-local configurations. 4. Educate developers about the risks of running Codex CLI on untrusted or newly cloned repositories without verification. 5. Integrate static analysis or automated scanning tools into CI pipelines to detect and block commits containing potentially dangerous MCP configurations. 6. Monitor developer machines and CI environments for unusual Codex CLI activity or unexpected command executions. 7. Consider isolating Codex CLI execution environments using containerization or sandboxing to limit the impact of potential command injection. 8. Maintain an inventory of all development tools and their versions to ensure timely patching of vulnerabilities. 9. Collaborate with supply-chain security teams to vet third-party and open-source repositories for malicious configurations before adoption.