OpenAI Codex Command Injection: Malicious GitHub Branch Names as a Token-Theft Path
BeyondTrust Phantom Labs reported that OpenAI Codex accepted a GitHub branch name into a container setup shell path, allowing command injection that exposed GitHub OAuth and installation tokens. The issue affected Codex Web and could be replicated through CLI, SDK, and IDE credentials; an automated variant used malicious branch refs to target multiple users working in a shared repository. OpenAI remediated the reported issues, but the defensive lesson remains: repository metadata must be treated as untrusted execution input.
GitHub metadata reached a shell command. BeyondTrust found that the branch parameter in the Codex task request was reflected into setup logic that fetched the selected repository and branch.
The branch name became command injection. Shell metacharacters in a GitHub branch ref could break out of the expected command context and run attacker-controlled commands inside the Codex container.
The target was the GitHub token Codex used for the task. During repository clone and review flows, Codex used OAuth or GitHub App installation tokens. The injected command could copy token-bearing remote configuration or logs and send the value outward.
The attack could scale through the repository. An attacker with branch-control rights could create or modify a malicious branch, hide payloads with Unicode spacing, or make the branch default so other Codex users trigger the payload.
Local Codex credentials expanded the path. The report also describes Codex CLI, SDK, and IDE credentials in ~/.codex/auth.json, which could be used to call backend APIs and retrieve task history or logs.
A Codex setup command becomes executable input as soon as repository metadata is interpolated into it. Before clone, checkout, or setup commands run, scan the resolved command or executable setup artifact for shell metacharacters, command substitution, hidden Unicode spacing, and network exfiltration patterns; pair that gate with structured process APIs instead of string-built shell commands.
Value-Level Capability Metadata & Data Flow Sink Enforcement
Very High
The stolen value was not just any string; it was a GitHub token tied to a user or installation. Agent infrastructure should label tokens as high-sensitivity runtime values and block them from unsafe sinks such as files the model can read back, task logs, outbound HTTP, shell arguments, and prompt-visible output.
Codex needs GitHub access to clone repositories, create reviews, and open pull requests, but those credentials should be short-lived, tightly scoped, audience-bound, and difficult to reuse outside the intended task. Repository, branch, workflow, and organization permissions should be minimized so a stolen token does not become broad GitHub lateral movement.
A Codex task acts on behalf of a user or GitHub App installation. Each container task should carry an accountable runtime identity, delegated GitHub scope, repo, branch, task ID, and expiry so defenders can prove which agent acted, under whose authorization, and which token should be revoked if the task is compromised.
The user's intent may be to review one branch or answer a question about one repository. The active Codex capability scope should reflect that narrow task: selected repo, selected branch, allowed GitHub actions, allowed network destinations, and allowed task-history access. A branch payload should not be able to widen the session into token exfiltration or cross-repository GitHub access.
BeyondTrust's automated variant exfiltrated tokens by sending outbound HTTP from the Codex container to attacker infrastructure. Default-deny egress, narrow allowlists, and proxy rules for setup and runtime phases would make a successful shell injection much less useful.
The report notes that Codex CLI, SDK, and IDE applications stored sensitive OpenAI account and refresh material in ~/.codex/auth.json. Local agent credentials should use platform-native secure storage where possible, short lifetimes, logout cleanup, and server-side deauthorization so a compromised endpoint cannot easily replay Codex backend access.
Once token exposure is suspected, response has to be faster than manual ticket handling. GitHub OAuth tokens, installation tokens, Codex access tokens, refresh tokens, and task sessions should be invalidated automatically when canaries fire, logs expose secrets, or anomalous GitHub API use appears.
What Defenders Should Do Now
Confirm that OpenAI's fixes are applied in the Codex products your team uses, then inventory every GitHub organization and repository where Codex or similar coding agents are authorized.
Audit GitHub App permissions and user OAuth grants for Codex-like agents. Remove broad organization-wide access where a task only needs one repo, one branch, or read-only review capability.
Treat GitHub branch names, ref names, repository names, PR titles, issue text, and setup parameters as untrusted input before they enter agent containers, shell commands, setup scripts, or logs.
Restrict Codex container egress during setup and runtime. Allow package registries and GitHub endpoints only when required, and alert on unknown outbound hosts.
If exposure is possible, revoke Codex-related GitHub tokens, rotate affected credentials, review GitHub audit logs for token use, and inspect Codex task history or container logs for leaked token material.
1 additional consideration
SCM-side branch naming and default-branch governance for AI agents
Beyond the techniques mapped above, teams should also add repository-side controls for the metadata that AI coding agents consume. A branch name can be valid for GitHub but dangerous once another system pastes it into a shell command.
Recommendation: Use GitHub rulesets, branch protection, pre-receive hooks where available, and CI checks to block refs with shell metacharacters, suspicious Unicode spacing, or command-substitution patterns before AI agents can run against them.
Conclusion
This Codex case shows how agent risk can start before the model makes any coding decision. A GitHub branch name is normal repository metadata, but once it is copied into a shell command inside an agent container, it becomes execution input. AIDEFEND ↗ maps the defensive baseline clearly: prevent unsafe code execution, stop tokens from flowing into logs or outbound HTTP, scope service credentials tightly, bind each agent task to accountable identity, restrict egress, monitor suspicious repository metadata, and revoke exposed tokens quickly.