How to Use OpenAI Codex Safely: Git, Sandbox, Backups, and Approvals

OpenAI Codex today can do far more than suggest individual lines of code. The coding agent can inspect files, modify source code, run commands, start tests, handle dependencies, and take on entire development tasks.

That makes Codex extremely powerful. At the same time, it creates a crucial difference from a classic chatbot: Codex can actually change something on your system.

A wrong command, a misunderstood instruction, or an overly broad permission can therefore have far greater consequences than a wrong text answer.

The good news: Codex has several built-in security mechanisms. OpenAI distinguishes in particular between sandboxing and approvals. The sandbox technically defines which files, directories, and network resources Codex may access. The approval rules, on the other hand, determine when Codex must ask for your consent before an action.

Anyone who wants to use Codex professionally shouldn't rely on that alone, though. The best strategy consists of several layers of protection:

Git protects your development state, the sandbox limits access, backups protect against data loss, and approvals prevent uncontrolled actions.

How safe is OpenAI Codex by default?

When used locally via CLI or IDE, the agent runs by default inside a sandbox enforced by the operating system. In the common workspace-write mode, Codex can work within the active project while network access stays disabled by default.

If Codex needs to write outside the workspace, or needs network access for a command, an additional approval may be required.

OpenAI describes the two security components in simplified terms like this:

• Sandbox: What is Codex technically allowed to do?
• Approval policy: When must Codex ask first?

This distinction matters. An approval prompt doesn't replace technical isolation. And a sandbox doesn't replace deliberate control over critical actions.

OpenAI itself reportedly runs Codex within clearly defined technical boundaries, combining sandbox rules, network restrictions, approvals, and logging.

1. Git should be mandatory before you use Codex

If you let Codex work on an important project, that project should generally be versioned with Git.

Even if Codex makes a mistake, you want to be able to trace at any time: What was changed? Which files are affected? What did the previous state look like? Can I fully roll the changes back?

This is exactly where Git's strength comes in. Before a larger Codex task, you should first establish a clean starting state.

git status

If Git already shows unsaved changes, review and save them first.

git add -A
git commit -m "Checkpoint before Codex changes"

For important projects, this state should also be pushed to a remote repository.

git push

Now you have a reproducible starting point. That doesn't mean Git replaces a full backup. Unversioned files, databases, upload directories, secrets, or external system configurations can live outside the repository. But Git is the first and most important protective layer for your source code.

Never let Codex work directly on your production branch

An even better approach is to create a dedicated branch for Codex.

git checkout -b codex/new-feature

Codex then works exclusively within that branch. Once the task is done, review the changes first:

git status
git diff

Only once everything looks correct and tests pass do you accept the changes. This approach separates AI-generated changes from your stable development state. Git worktrees make that separation even more convenient.

2. Git worktrees: one of Codex's best security features

The current Codex desktop app supports Git worktrees directly. A worktree creates a separate working directory for a branch. That lets Codex work on a feature while your original checkout stays untouched.

OpenAI explicitly describes worktrees as a way to isolate the changes from a Codex chat in a separate Git workspace. That's especially useful when several Codex agents work in parallel.

Agent A might fix a bug. Agent B develops a new API at the same time. Agent C writes tests. Instead of letting every agent loose on the same file system, each agent gets its own worktree. That significantly reduces the risk of changes overwriting each other. Before picking a coding agent, it's also worth reading Claude Code vs. OpenAI Codex: Which Coding Agent Is Better? (Read article), since the two tools handle branches, worktrees, and approvals differently.

The Codex app now also has built-in Git features. You can view changes, revert individual hunks, stage files, create commits, push branches, and create pull requests. For production development projects, that's considerably safer than an agent working directly in the main checkout.

3. Understanding the Codex sandbox

One of Codex's most important settings is the sandbox mode. Current modes include:

• read-only
• workspace-write
• danger-full-access

workspace-write is especially relevant for normal development work. It lets Codex read and modify files within the workspace and run normal local commands. Outside that scope, additional restrictions or approvals kick in.

read-only makes sense for pure analysis. Example: you first just want to know: "Analyze this repository and explain what changes would be needed to migrate to PHP 8.5. Don't change any files yet." In that case, Codex doesn't need write access at all.

If you haven't installed Codex yet, Install and Use Codex CLI on Linux (Read article) walks through setting up the CLI. In the CLI, the desired environment can be started explicitly:

codex --sandbox read-only --ask-for-approval on-request

For normal development work:

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

That combination is a sensible starting point for many projects. OpenAI also refers to workspace-write combined with on-request as a typical auto mode.

4. "Full access" should stay the exception

Be especially careful with settings like danger-full-access or any option that fully bypasses the sandbox and approvals.

OpenAI itself notes that danger-full-access removes the sandbox restrictions. Codex then has considerably broader access to the file system and network.

That doesn't mean this mode is categorically forbidden. There are legitimate use cases. For example, Codex can run inside a fully isolated development container or a purpose-built virtual machine. In that case, the container or VM forms the actual security boundary.

It becomes a problem, though, when Codex is given full access directly on a production developer workstation that also holds SSH keys, configuration files, database dumps, customer data, and production credentials.

The greater the agent's permissions, the greater the isolation of its environment needs to be.

5. Don't grant network access unnecessarily

Codex doesn't need direct internet access for many tasks. If the source code is already local and build tools and dependencies are installed, a large part of the development work can happen offline.

In the normal local workspace-write mode, network access is disabled by default. It can be enabled selectively, and can now also be restricted with network rules.

That matters for security. A compromised package, a manipulated repository, or a prompt injection (Read article) could, in theory, try to exfiltrate data to external systems.

So the question shouldn't be "Why shouldn't Codex get internet access?" It should be "Why does this specific task need internet access?" If there's no good reason, it's safer to leave the network disabled.

OpenAI itself reportedly doesn't give Codex unrestricted outbound network access internally either, instead relying on controlled network rules and known destinations.

6. Review approvals deliberately — don't rubber-stamp them

Approvals lose their security value the moment users approve every request automatically. When Codex wants to perform an action outside its current permissions, take a moment to check:

• What command is about to run?
• Why does Codex need this permission?
• Which files are affected?
• Is network access required?
• Could the task be done with fewer permissions?

OpenAI recommends choosing the smallest scope needed to continue the task whenever different approval scopes are available. Instead of giving an agent blanket access to your entire home directory, it's better to hand it the specific project directory instead.

That's classic least privilege: a process only gets the permissions it actually needs. The same principle applies to the tools an AI agent calls through interfaces — see How to Operate MCP Servers Securely: Permissions, Tools, and Risks Explained (Read article) for more.

7. Backups: Git alone isn't enough

A Git repository protects your source code very well. But a complete project usually consists of much more than that. That includes databases, user uploads, .env files, certificates, deployment configurations, local development data, or configuration living outside the actual repository.

That data needs a separate backup strategy. Especially important: the backup shouldn't live in the same directory Codex has write access to.

If /home/user/project is the Codex workspace, for example, a backup under /home/user/project/backup only provides limited additional protection.

A technically separate storage location is better — for example a backup server, NAS, snapshot system, external repository, or other storage the Codex process has no direct write access to. That way, the backup also protects against accidental deletion or overwrite operations.

8. Production servers shouldn't be a Codex playground

Pointing Codex directly at a production web server over SSH and then giving it the task "please optimize my server" is not a good security strategy. If you still want to run Codex remotely on a Linux server, Codex Remote Control on Linux (Read article) covers the necessary safeguards.

An AI can interpret a task logically correctly and still make a technically undesirable change. The classic chain is more professional:

Development → Test → Staging → Review → Production

Codex works first in development or an isolated test environment. The changes are then tested. A Git commit or pull request is then created. Deployment only happens after human review.

That exact review principle also shows up in the Codex cloud workflow: results and diffs are meant to be reviewed before they become a pull request or an accepted change.

9. Pull requests instead of direct changes

For teams, a pull-request workflow is especially recommended. Codex first creates a change in its own branch. A pull request is then created from it. Now automated tests, CI/CD pipelines, and human code review can run.

Codex itself can also review pull requests. OpenAI offers a Codex code review feature for this that analyzes the PR diff and flags potential problems.

That creates an interesting security architecture: Codex generates code. Tests check the code. A review checks the diff. A human decides on the merge. Only then does deployment happen.

AI speeds up the development process without fully taking over the critical approval step.

10. Use AGENTS.md as a security guardrail

Besides technical permissions, you can also give Codex durable project rules. An AGENTS.md file is well suited for this.

OpenAI describes this file as a persistent repository instruction that Codex takes into account while working. Among other things, it can define build commands, tests, conventions, and review rules.

It could, for example, contain rules like these:

# Security rules

Never work directly on main.
Create a separate branch for changes.
Never modify production configuration.
Never delete databases or backup files.
Never run deployments to production.
Show critical changes before executing them.
Run the existing tests after code changes.
Never commit credentials or secrets to Git.

A file like this doesn't replace a sandbox. It complements it. The technical sandbox prevents certain actions. AGENTS.md additionally tells Codex how to work within the environment it's allowed to use.

A sensible Codex security configuration

For a local development environment, a deliberately conservative configuration might look like this:

approval_policy = "on-request"
sandbox_mode = "workspace-write"
allow_login_shell = false

[sandbox_workspace_write]
network_access = false

This lets Codex work within the workspace but doesn't automatically grant open network access. OpenAI exposes these parameters through config.toml, letting you configure sandbox mode, approval policy, and network access.

The ideal setting naturally depends on the development environment. A private test project needs different safeguards than the source code of a production business system.

My Codex security checklist before any larger task

• The project is versioned with Git.
• The current stable state has been committed and, where possible, pushed to a remote repository.
• Important data has an independent backup.
• Codex works on a separate branch or worktree.
• The sandbox is set to workspace-write, or read-only for analysis.
• Network access is only enabled when actually needed.
• Approval requests are read before being confirmed.
• Production credentials and secrets aren't unnecessarily reachable from the workspace.
• Changes are reviewed with git diff or through a pull request.
• Deployment and merging only happen after tests and review.

Following these points significantly reduces the risk of using a coding agent.

Why backups matter more as AI agents get more autonomous

AI used to mostly suggest code. A human had to copy, save, and run that code. Modern coding agents change that division of roles.

Codex can independently analyze files, make changes, run commands, and handle longer-running tasks. As autonomy increases, you need more technical safeguards, not fewer.

The key security question isn't "Can I trust Codex?" It's "What happens if Codex makes the wrong call?"

If the answer is "I look at the Git diff and discard the branch," your environment is well prepared. If the answer is "Then I hope my production data is still there," your security architecture is missing.

Conclusion: Codex can be productive — but not unlimited

OpenAI Codex can massively speed up development processes. But a capable AI agent should meet the same security principles that apply to administrators, developers, and automation systems: minimal permissions, clear boundaries, versioning, backups, tests, reviews.

Git makes changes traceable. Worktrees isolate parallel tasks. The sandbox limits technical access. Approvals protect especially critical actions. Backups ensure that even a serious mistake doesn't lead to permanent data loss. And pull requests create a controlled boundary between AI-generated code and production systems.

The best Codex configuration therefore isn't the one where the agent is allowed to do everything. The best configuration is the one where Codex is allowed to do exactly what its current task requires — and not one step more.

Frequently asked questions about Codex security

Can Codex modify files on my computer?

Yes. When used locally, Codex can modify files within the approved workspace depending on the sandbox and permissions in place. In the common workspace-write mode, write access is limited to the workspace.

Should I use Codex without a sandbox?

For normal development projects, that's not recommended. danger-full-access removes key sandbox boundaries and should only be used deliberately, for example when another technical isolation layer such as a suitable container or VM is in place.

Do I need Git for Codex?

Codex also works without Git. For important development projects, however, Git is strongly recommended because changes can be tracked, compared, and rolled back. Codex now also supports worktrees, diffs, commits, pushes, and pull request workflows directly.

Is Git also a backup?

No. Git primarily protects versioned files. Databases, uploads, secrets, and unversioned files still need an independent backup strategy.

What is the safest sandbox mode for Codex?

For pure analysis, read-only is a good fit. For normal local development work, workspace-write is a sensible starting point. danger-full-access should only be used in deliberately isolated or trusted environments.

Should Codex get direct access to production servers?

Ideally not. A development and staging workflow with Git, tests, review, and then controlled deployment is safer.

Are Codex worktrees useful?

Yes. Especially with several parallel tasks or agents, worktrees prevent changes from different tasks from colliding directly in the same checkout. Codex now supports this form of isolation directly in the desktop app.

Further reading and sources

Install and Use Codex CLI on Linux (Read article)

Claude Code vs. OpenAI Codex: Which Coding Agent Is Better? (Read article)

How to Operate MCP Servers Securely: Permissions, Tools, and Risks Explained (Read article)

Prompt Injection Explained: How Attackers Hijack AI Agents (Read article)

Codex Remote Control on Linux (Read article)

As of August 2026. This article follows the current state of official OpenAI documentation on Codex sandboxing & approvals, Codex configuration, Git worktrees, local development environments, Codex Cloud, and GitHub code reviews.