IMPORTED / SAFETY

IS OPENAI CODEX SAFE? SECURITY ANALYSIS | VIBEEVAL

Is OpenAI Codex safe? The short answer

Yes, OpenAI Codex is safe — and like every other agent, it is exactly as safe as how you scope it. The cloud agent runs each task in a sandboxed container, isolated from your machine, and its output is a pull request you get to review. The trust boundary moves out of the container and into the things you control: the AGENTS.md files that steer it, the environment variables you hand its sandbox, whether tasks get internet access, and how seriously your team reviews agent-authored PRs. The Codex CLI is a different posture entirely — it runs locally with your developer permissions and deserves local-agent caution.

What’s safe by default

  • Sandboxed cloud execution. Each cloud task runs in its own container. A misbehaving task can trash the sandbox, not your laptop.
  • PR-gated output. The cloud agent’s changes land as pull requests. Nothing reaches your default branch without whatever review process you enforce.
  • Configurable network access. Internet access for cloud tasks can be granted or denied — a real lever most local agents don’t have.
  • Repo-scoped access. Codex works on the repos you connect, not your whole account, if you scope the connection that way.

Where the risk lives

1. AGENTS.md is part of the prompt

AGENTS.md files are persistent instructions the agent follows — repo-level configuration that is also prompt. That is exactly why they are a target. An attacker-controlled AGENTS.md changes agent behavior: a contribution PR that tweaks it, a vendored dependency that carries one, or a maintainer account compromise can instruct the agent to prefer a malicious package, weaken auth logic, or modify CI on its next run.

Fix. Put AGENTS.md behind a CODEOWNERS rule so changes require maintainer review. Audit its history (git log -p -- AGENTS.md '**/AGENTS.md') and treat any diff to it in review like a diff to your CI config. The same file-as-prompt logic behind poisoned CI configs applies here.

2. Repo content and issues are untrusted input

When Codex works an issue, the issue body is prompt. So are READMEs, code comments, and fixtures it reads along the way. On a public repo, anyone who can open an issue can attempt indirect prompt injection — instructions dressed as a bug report, aimed at the agent rather than the maintainer.

Fix. Read issues before assigning them to the agent. Rely on the two structural controls: no internet access by default (no exfiltration path) and mandatory PR review (no unreviewed path to merge).

3. Sandbox env vars are readable by the agent — and by what it runs

Secrets configured for the Codex environment are available during runs. That includes availability to install scripts of packages the agent decides to add. A sandbox provisioned with production credentials plus internet access is one malicious postinstall script away from a leak.

Fix. Keep the sandbox environment minimal: build and test credentials only, scoped and revocable. Never mirror production env into it. Rotate anything long-lived.

4. The Codex CLI runs with your local permissions

The CLI executes commands in your terminal as you. No container. It can read your dotfiles, your SSH keys, every repo on disk — bounded only by its approval mode and your restraint. Running it full-auto inside an untrusted repo combines local shell access with attacker-influenced input.

Fix. Keep command approval prompts on for normal work. For untrusted or unfamiliar repos, run the CLI in a container or use the cloud agent instead — that is what the sandbox is for.

5. Agent-authored PRs get over-trusted

The failure mode is not that Codex writes obviously bad code — it is that it writes plausible code fast, and reviewers calibrate to the stated task. The intentional diff looks right; the dangerous change is the one the reviewer didn’t notice, three files away. Hallucinated or typosquatted dependencies ride the same wave: a lockfile diff nobody reads is where a phantom package lands. Run new dependency names through the Package Hallucination Scanner.

Fix. Branch protection with required human review on every Codex PR. Review dependency manifests first, then the full diff. Never merge on green CI alone.

6. Generated code ships with predictable vulnerabilities

Codex produces the same family of bugs every AI coder produces: routes without auth gates, handlers that trust input, CRUD endpoints that fetch by ID without checking ownership (BOLA), permissive CORS, verbose error responses. The sandbox and the PR flow do nothing about this — it is the content of the code, not the delivery mechanism.

Fix. Treat agent commits like contractor commits: PR review, SAST in CI, dynamic scan against the deployed app. The full taxonomy is in vibe coding vulnerabilities.

A starting posture for a team adopting Codex:

  • Internet access for cloud tasks: off by default; enable per-task with a narrow allowlist when genuinely needed.
  • Sandbox env vars: build/test only, scoped tokens, nothing production.
  • Branch protection on every branch Codex targets: required human review, required status checks, no force push.
  • AGENTS.md behind CODEOWNERS, audited like CI config.
  • Secret scanning (gitleaks + Push Protection) and npm audit / pip-audit as required checks on every PR.
  • CLI: approval prompts on; containers for untrusted repos.

Add access as tasks demonstrate the need, not before.

Enterprise considerations

For teams adopting Codex at scale:

  • Repo access scoping — connect the agent to specific repos, not the org; review the grant list periodically.
  • Environment governance — who can add env vars to Codex environments, and how additions are reviewed.
  • Network policy — a written default (internet off) with a documented exception process.
  • Agent-authored change tracking — label Codex PRs so incident response can answer “which changes came from the agent” without archaeology.
  • Data handling — review OpenAI’s enterprise terms for code retention and training questions against your compliance requirements.

Platform-side controls cover the sandbox. They do not cover the security of the code the agent writes into your repo, the packages it adds, or the instructions your own files feed it. Be precise about which side of that boundary your audit lives on.

Codex cloud vs Codex CLI — when to pick which

  • Codex cloud. Sandboxed, PR-gated, network-controllable. Strongest for delegated tasks on connected repos, and the right choice for anything touching code you don’t fully trust.
  • Codex CLI. Local, fast, terminal-native — and running with your permissions. Strongest for interactive work in repos you trust, with approval prompts on.

The cloud agent’s sandbox absorbs risks the CLI passes straight to your workstation. Match the form to the trust level of the code.

After every Codex task

  • Read the entire PR diff, including files outside the stated task.
  • Diff package.json / requirements.txt / lockfiles first; verify every new package name character-by-character.
  • Search the diff for removed auth checks, widened CORS, softened test assertions, new eval(/exec( calls, string-concatenated SQL.
  • Confirm AGENTS.md, CI, and workflow files are unchanged unless the task required it.
  • Run security tests separately — agents sometimes “fix” a failing security test by relaxing the assertion.

The verdict

OpenAI Codex is safe to use. The cloud agent’s sandbox-plus-PR design is one of the better default trust postures in the agent space: your workstation is out of the blast radius and every change passes a review gate you control. The risk shifts to configuration and discipline — AGENTS.md hygiene, sandbox env scoping, internet-access policy, real review of agent PRs, and treating the CLI as the local shell agent it is. Lock those down and it is production-appropriate for any team with decent code-review and CI hygiene.

Scan your application

Let VibeEval scan your deployed application for the vulnerabilities Codex (and every other AI coder) most often leaves in.

/ FAQ

COMMON QUESTIONS

01
Is OpenAI Codex safe to use?
Yes. The cloud agent runs each task in a sandboxed container isolated from your workstation, and every change arrives as a pull request you can review before it merges. The risks are not in Codex itself — they are in what you feed it (AGENTS.md, issues, repo content are all part of the prompt), which secrets you configure for its sandbox, and how carefully you review its PRs.
Q&A
→
02
What is the difference between Codex cloud and the Codex CLI, security-wise?
The cloud agent works on a connected GitHub repo inside a sandboxed container and opens PRs — your workstation is never in the blast radius. The Codex CLI runs locally in your terminal and executes commands with your developer permissions, so it can touch anything you can: dotfiles, SSH keys, other repos. The CLI needs the same caution you would apply to any local agent with shell access.
Q&A
→
03
Can Codex be prompt-injected?
Yes, like every coding agent. Repo content, issue text, and AGENTS.md files are all inputs the agent follows. An attacker who can edit any of them — via a contribution PR, a public issue, or a compromised dependency vendored into the tree — can attempt to steer the agent. Mandatory PR review and denying internet access to cloud tasks are the two controls that contain it.
Q&A
→
04
Can Codex read my secrets?
It can read whatever you configure for its environment. Env vars attached to the cloud sandbox are readable by the agent during runs, and by anything it executes — including install scripts of packages it adds. Scope sandbox env vars to the minimum the task needs and never mirror your production environment into it.
Q&A
→
05
Should Codex cloud tasks have internet access?
Default to no. Internet access is the exfiltration path: a prompt-injected agent with network access can post source code and env vars to an attacker endpoint. Deny it by default, enable per-task only when a task genuinely needs to fetch something, and keep secrets out of the sandbox when it is on.
Q&A
→
06
Is it safe to merge Codex PRs automatically?
No. The recurring incident shape is a PR whose intentional diff looks right while the dangerous change sits in a file the reviewer skimmed — a relaxed auth check, a widened CORS config, a softened test. Require at least one human review on every agent-authored PR and read the whole diff, not just the stated change.
Q&A
→
07
What is AGENTS.md and why does it matter for security?
AGENTS.md files hold persistent instructions the agent follows on every task in the repo — effectively configuration that is also prompt. Anyone who can change AGENTS.md changes agent behavior, which makes it a target: gate changes behind CODEOWNERS review and audit its history like you would audit CI config.
Q&A
→
/ NEXT STEP

SCAN YOUR APP

14-day trial. No card. Results in under 60 seconds.

START FREE SCAN →