Skip to content

Guide

AI coding agent permissions and YOLO mode: a safer setup

Permission modes in Claude Code, Codex and Cursor, what skip-all modes really skip, what a repository can change, and the agent settings that should not be committed.

· 8 min read · By the vetkit team

A small robot reaches for a big lever on a striped warning panel, while the developer rushes in with a raised hand and a padlock to stop it.A small robot reaches for a big lever on a striped warning panel, while the developer rushes in with a raised hand and a padlock to stop it.

Permission modes in three tools

Every AI coding agent balances two things: how often it interrupts you, and how much it can do without asking. The settings have different names in each tool but the same shape: a mode that asks, a mode that lets an automatic reviewer decide, and a mode that skips everything, informally called YOLO mode.

Permission modes in Claude Code, Codex and Cursor
ToolModes, per its documentationSkip-all setting
Claude CodeManual, auto (a classifier reviews actions; the starting mode for interactive sessions), acceptEdits, plan, dontAskbypassPermissions, also started with the --dangerously-skip-permissions flag
OpenAI CodexSandbox modes read-only, workspace-write, danger-full-access, combined with an approval policy such as on-request or never--dangerously-bypass-approvals-and-sandbox, alias --yolo
CursorAuto-review (recommended default), AllowlistRun Everything

What skip-all modes really skip

Skip-all modes remove more than the prompts. In Codex, the flag removes both approvals and the sandbox. Cursor describes Run Everything as running every tool call automatically with no sandbox and no reviewer. Claude Code’s bypass mode also skips prompts for writes to its own .claude directory and to .git.

The vendors are consistent about where these modes belong: Claude Code says to use bypass mode only in isolated environments such as containers or VMs, and Codex marks its flag as elevated risk and not recommended. Even in a container, anything mounted into it, such as a cloud credential or an SSH agent, is fair game. The guide to what agents can access lists what that usually includes.

What a repository can change

Agent configuration increasingly lives in the repository, next to the code: .claude/ settings, .codex/config.toml, .cursor/mcp.json, hook definitions, and instruction files such as AGENTS.md and CLAUDE.md. That is convenient for teams, and it means a git clone can change how an agent behaves.

  • Trust gates help. Codex loads a project’s .codex/ layer only after you trust the project. Claude Code applies a repository’s allow rules only after each teammate trusts the folder, and ignores bypassPermissions as a default mode in project settings.
  • Not everything is gated the same way. Hooks, MCP server definitions and instruction files still arrive with the repository; MCP servers have their own approval prompt, and Cursor’s workspace trust is off unless you enable it.
  • Older versions behave differently. A setting that current releases ignore may still be honoured by an older client on someone’s machine, and its presence tells you the project expects agents to run unattended.

Agent settings not to commit

These are the patterns worth catching in review before they reach the main branch:

  • Approvals turned off: bypassPermissions as a default mode, a subagent with permissionMode: bypassPermissions, or a package script that starts an agent with --dangerously-skip-permissions or --dangerously-bypass-approvals-and-sandbox.
  • Allow rules that pre-approve anything: Bash(*), or wildcards on shells, interpreters, package runners and network tools such as Bash(curl:*) or Bash(npx:*).
  • Hooks that download and run a script, for example piping curl into a shell.
  • MCP servers that are not pinned, launched from a remote script, reached over plain HTTP, or configured with a hard-coded credential.
  • Hidden text in instruction files: HTML comments or invisible Unicode in AGENTS.md or CLAUDE.md that a reviewer cannot see but the agent reads.
.claude/settings.json to flag in review
{  "permissions": {    "defaultMode": "bypassPermissions",    "allow": ["Bash(*)", "Bash(curl:*)", "Bash(npx:*)"]  }}

A safer baseline

  1. Keep the default or auto mode on laptops; reserve skip-all modes for disposable environments.
  2. Commit narrow allow rules for the exact commands your project runs, and deny reads of secrets.
  3. Pin MCP server versions and keep their credentials in environment variables, not in the file.
  4. Turn on the sandbox where it is optional, and keep network access to an allowlist.
  5. Treat changes to agent configuration and instruction files as security-relevant in review.
A narrower .claude/settings.json
{  "permissions": {    "allow": ["Bash(npm run test:*)", "Bash(npm run lint)"],    "deny": ["Read(./.env)", "Read(./secrets/**)"]  }}

Allow rules ending in a wildcard are only as safe as the command before it: a rule for npm run test is narrow, a rule for node or curl is not.

Where vetkit fits

The vetkit repository audit checks committed agent configuration as part of its AI code risks suite: approval bypass settings and flags, allow rules that pre-approve arbitrary shell or network commands, hooks that run remote scripts, unpinned or remotely launched MCP servers, MCP servers over plain HTTP or with hard-coded credentials, and hidden comments or Unicode in agent instruction files. The same rules are shared with the @vetkit/mcp server and with Agent Watch, which reports what agents actually do on team machines; the monitoring guide covers that side.

Sources

We read the statements about each tool from its own documentation on :

Product names are trademarks of their respective owners. vetkit is not affiliated with, endorsed by or sponsored by them. Spotted something out of date? Email contact@vetkit.dev and we will correct it.

Request early access

Tell us a little about your team and the repositories you want to audit. We onboard teams in small batches and will reply by email.

We use these details only to reply to your request. Privacy policy