Is --dangerously-skip-permissions safe?

Practically everyone running Claude Code seriously has typed this flag. Usually around the third time an agent stopped mid-refactor to ask whether it could run the test suite it had already run twice. The impulse is completely reasonable. The question is what you're actually agreeing to.

What the flag disables

There are two separate flags, and the difference matters:

The equivalent persistent setting is permissions.defaultMode: "bypassPermissions", and there's a counterpart guard — disableBypassPermissionsMode — that removes the ability to opt in from that settings scope entirely.

What's disabled is the *asking*, not any sandbox. Claude Code does not run tools in a container by default. The agent gets your user account, your filesystem, and your network. Bypassing permissions removes the only thing standing between a plausible-looking command and your machine.

The inheritance problem

This is the part that people underweight. An agent running as you inherits everything you've authenticated:

• Your SSH keys — including agent-forwarded ones, and push access to every repo you can push to.
• Your gh / git credentials, so 'clean up the branches' can become a force-push to a shared branch.
• Cloud CLI sessions: aws, gcloud, kubectl contexts pointing wherever you last pointed them.
• ~/.npmrc, ~/.pypirc, and other publish tokens.
• Every .env file on disk, and anything reachable on your VPN or localhost.

None of that requires the model to be malicious. It requires one confidently wrong command — a git checkout . that discards two hours of uncommitted work, a cleanup script whose glob resolves wider than intended, a migration run against the terminal's current DATABASE_URL. These are ordinary mistakes with an unusual blast radius, and the permission prompt exists specifically to catch them.

When bypassing is genuinely fine

This isn't an argument that the flag should never be used. It's an argument about where. Bypassing is reasonable when all of these hold:

• The environment is disposable — a container, a VM, a fresh CI runner. If the worst case is docker rm, the worst case is fine.
• It holds no credentials you care about. No SSH keys, no cloud sessions, no publish tokens, no production database URL.
• The network is constrained, ideally absent. This is the condition the CLI's own help text singles out.
• The work is reconstructible — everything valuable is committed and pushed somewhere the agent can't reach.

That describes a CI job or a throwaway sandbox well. It describes a laptop with your work SSH key on it not at all.

The safer middle

Most people who want the flag don't want *no oversight*. They want *fewer interruptions*, which is a different thing and has better answers.

1. Allowlist the boring commands

The prompts that drive you to the flag are almost always the same five commands. Approve them once, as a rule, instead of thirty times as a decision:

{
  "permissions": {
    "defaultMode": "acceptEdits",
    "allow": [
      "Bash(npm run test *)",
      "Bash(npm run lint *)",
      "Bash(git status)",
      "Bash(git diff *)",
      "Bash(git log *)"
    ],
    "deny": [
      "Bash(rm -rf *)",
      "Bash(git push *)",
      "Bash(gh pr merge *)",
      "Read(./.env)",
      "Read(~/.aws/**)"
    ]
  }
}

This gets you most of the fluency of bypass mode while keeping the irreversible category behind a human. Note that deny takes precedence over allow, so the floor holds even as the allowlist grows. Full syntax in permission modes explained.

2. Isolate instead of trusting

If you want real autonomy, put the agent somewhere the blast radius is bounded rather than removing the check. A container with a mounted worktree, no SSH agent, and a scoped token gives you *more* freedom than bypass-on-laptop, because you can genuinely stop paying attention.

3. Fix the latency, not the policy

The honest reason the flag is tempting is that being asked is expensive — not the decision, the *noticing*. An agent blocks; you find out eleven minutes later because you were in a different window. Do that four times an afternoon and turning permissions off starts to look like productivity.

But that's a notification problem wearing a permissions costume. If a blocked agent reached you in two seconds wherever you were on screen, the prompt would cost you a click and the flag would lose most of its appeal. That's the whole thesis behind BubbleCode, and it's also achievable in cruder forms with hooks and macOS notifications.

If you're going to do it anyway

1. 01Commit and push first. Uncommitted work is the most common real loss, and it's entirely preventable.
2. 02Run in a dedicated worktree (claude --worktree) so the damage is scoped to a branch you can delete.
3. 03Unset what you don't need for this task — SSH_AUTH_SOCK, cloud profile env vars, DATABASE_URL.
4. 04Set --max-budget-usd so a runaway loop is bounded in cost as well as scope.
5. 05Keep deny rules in place. Even in bypass mode, deny rules and PreToolUse hooks are your last line — a guardrail hook can hard-block pushes regardless of mode.
6. 06Never on a machine with production access. There's no configuration that makes that one okay.