A coding agent that can edit files and run commands can also delete files, leak a key or push something you didn't mean to ship. You don't fix that by turning the agent off. You fix it by deciding, ahead of time, what it may do without asking.
This guide shows how to run coding agents safely with the controls Claude Code and Codex already ship: permission modes, sandboxes, approval policies and deny rules. It also covers the habits that keep secrets out of reach. Everything here comes from the vendors' own documentation, linked as we go.
Three questions to run coding agents safely
Every safety setting answers one of these:
- What can the agent touch? Files, folders, the network. This is the sandbox.
- When must it ask first? Edits, shell commands, network calls. This is the permission mode or approval policy.
- What is never allowed, no matter what? Deleting your home folder, pushing to
main, reading.env. These are deny rules and protected paths.
Get these three right and you can let an agent work for long stretches without approving every keystroke.
Claude Code permission modes
Claude Code calls its main control a permission mode. You switch modes with Shift+Tab in the CLI, the mode indicator in VS Code, or the mode selector in the desktop app (Claude Code permission modes). The docs list what runs without asking in each mode:
| Mode | What runs without asking | Best for, per the docs |
|---|---|---|
Manual (default) |
Reads only | Reviewing every action yourself, sensitive work |
acceptEdits |
Reads, file edits and common filesystem commands | Iterating on code you're reviewing |
plan |
Reads, plus classifier-approved commands when auto mode is available | Exploring a codebase before changing it |
auto |
Everything, with background safety checks by a classifier | Long tasks, reducing prompt fatigue |
dontAsk |
File reads and pre-approved tools; anything that would prompt is denied | Locked-down CI and scripts |
bypassPermissions |
Everything | Isolated containers and VMs only |
Two details matter more than the table:
- Auto mode is not a guarantee. The docs say plainly that auto mode "reduces permission prompts but does not guarantee safety". With Claude Code v2.1.283 or later, auto mode is the built-in starting mode for interactive terminal and VS Code sessions, so check which mode you're in before a sensitive task.
- Deny rules always win. "Deny rules block in every mode, including
bypassPermissions." If something must never happen, write a deny rule instead of hoping a mode will catch it. Writes to a small set of protected paths, which keep your repository state and Claude Code's own configuration safe, are also never auto-approved outsidebypassPermissions.
Instruction files don't replace these controls. Claude Code's docs describe CLAUDE.md as context, not enforced configuration, and recommend a PreToolUse hook to block an action regardless of what Claude decides (Claude Code memory docs).
Codex sandbox and approval policies
Codex splits the same idea into two settings: a sandbox that limits what the agent can touch, and an approval policy that decides when it must stop and ask (Codex security docs).
- Network access is off by default. Locally, Codex uses an OS-enforced sandbox that typically limits it to the current workspace.
- The Auto preset is
--sandbox workspace-write --ask-for-approval on-request. Codex can read files, make edits and run commands in the working directory, and asks before editing outside the workspace or running commands that need the network. - Read-only (
--sandbox read-only) is the mode for chatting and planning without changes. - Protected paths stay read-only even in
workspace-write: the.gitfolder, plus.agentsand.codexwhen they exist. --yolois the alias for--dangerously-bypass-approvals-and-sandbox: no sandbox and no approvals. The docs mark it "Elevated Risk" and "not recommended".
If a task really needs the network in the default sandbox, enable it explicitly in config.toml instead of dropping the sandbox:
[sandbox_workspace_write]
network_access = true
One migration note: Codex no longer supports approval_policy = "untrusted", and the docs say the retired setting can stop Codex from starting. Remove it from old config files.
Keep secrets out of the agent's reach
Most leaks don't need a malicious agent. They happen because a key was sitting where the agent could read it, paste it or commit it.
- Keep secrets in environment variables, not in code, prompts, AGENTS.md or MCP config files. Cursor supports
${env:NAME}inmcp.json, Claude Code expands${VAR}in.mcp.json, and Codex can read a bearer token from an environment variable withbearer_token_env_var(Cursor MCP, Claude Code MCP, Codex MCP). - Never give an agent a production secret it doesn't need. On Supabase, the secret key bypasses Row Level Security. Develop against a separate project, and connect the Supabase MCP server with
read_only=trueand aproject_ref(Supabase MCP). - Leave GitHub push protection on. Push protection for users is on by default and blocks supported secrets when you push to public repositories (GitHub Docs).
- Rotate first, clean up second. If a key reaches a commit, revoke it right away. Our guide to Git and GitHub basics for vibe coders covers
.gitignoreand untracking files.
A safe default setup
Here's the setup we'd start with for a solo builder or small team:
- Work on a branch with a clean
git status. Then every agent change is a diff you can review or throw away. - Start in a mode that asks before edits (Manual or
acceptEditsin Claude Code, read-only or Auto in Codex) until you trust the task. - Add deny rules for anything that must never happen, such as reading
.envfiles or pushing tomain. Our Claude Code safe settings starter has these rules ready to copy, and the Claude Code hooks starter adds a PreToolUse hook as a second layer. - Keep the network off unless the task needs it, and enable it per project.
- Scope every MCP server to one project, read-only where possible. See MCP security best practices.
- Reserve full bypass modes for throwaway containers or VMs, never your laptop with your SSH keys and browser sessions on it.
- Review the diff before you merge. Our checklist for reviewing AI-generated code puts the riskiest checks first.
Keep reading
- MCP security: how to use MCP servers without leaking data
- Cursor vs Claude Code vs Codex: how to pick an AI coding agent
- Pre-deploy check skill for coding agents
FAQ
What is the safest way to run a coding agent?
Work on a branch with a clean git status, start in a mode that asks before edits, add deny rules for anything that must never happen, keep network access off unless needed, and review the diff before merging.
What does bypassPermissions do in Claude Code?
bypassPermissions lets everything run without asking. Anthropic says it is for isolated containers and VMs only. Deny rules still block in that mode.
Does Codex have internet access by default?
No. Codex runs with network access turned off by default. In the workspace-write sandbox you can enable it with network_access = true under [sandbox_workspace_write] in config.toml.
What is --yolo in Codex?
--yolo is the alias for --dangerously-bypass-approvals-and-sandbox, which runs Codex with no sandbox and no approvals. OpenAI marks it as elevated risk and not recommended.
