[BUG] Bypass Permissions warning silently persists acceptance forever — prompt says "while running in … mode" but the choice is permanent

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Accepting the Bypass Permissions warning prompt silently writes skipDangerousModePermissionPrompt: true to ~/.claude/settings.json permanently, suppressing the warning for all future sessions on the machine. The prompt never states the choice is saved, offers no scope control, and its wording actively implies the acceptance is scoped to the current run. This is a mismatch between what the UI says and what it does.

The prompt (verbatim):

  WARNING: Claude Code running in Bypass Permissions mode

  In Bypass Permissions mode, Claude Code will not ask for your approval before running potentially
  dangerous commands.
  This mode should only be used in a sandboxed container/VM that has restricted internet access and
  can easily be restored if damaged.

  By proceeding, you accept all responsibility for actions taken while running in Bypass Permissions
  mode.

  https://code.claude.com/docs/en/security

  ❯ 1. No, exit
    2. Yes, I accept

  Enter to confirm · Esc to cancel

The copy may be read to frame acceptance as per-run, not permanent:

• "By proceeding, you accept all responsibility…" — reads as accepting responsibility for the act of proceeding now.
• "…for actions taken while running in Bypass Permissions mode." — scopes the acceptance to running in the mode, which could be interpreted as referring to this session.

A user who reads the prompt literally might to be asked again next time. Instead, the single "Yes, I accept" both starts the session and permanently disables the warning — a scope the text does not disclose and arguably denies. Silently persisting a security-consent decision while describing it as per-run is the defect.

What Should Happen?

One of:

1. The acceptance is scoped to the current session, and the warning reappears on the next launch; or
2. If acceptance is persisted, the prompt explicitly says so and offers a scope choice — e.g. "Yes, for this session only" vs "Yes, and don't ask again on this machine" — with only the "always" option writing skipDangerousModePermissionPrompt: true.

At minimum, the prompt copy should disclose that accepting saves the choice (e.g. "Accepting saves this choice to settings.json; you will not be warned again on this machine.").

Error Messages/Logs

None — this is a UI/behavior bug with no error output.

Steps to Reproduce

1. Edit ~/.claude/settings.json to set bypass mode as the default:

``json
{
"permissions": {
"defaultMode": "bypassPermissions"
}
}
``

1. Start a new session (claude). The Bypass Permissions warning screen (quoted in "What's Wrong?") appears.
2. Choose "2. Yes, I accept" and press Enter.
3. Inspect ~/.claude/settings.json again.

Observed: a new key has been written and persisted automatically:

{
  "permissions": {
    "defaultMode": "bypassPermissions"
  },
  "skipDangerousModePermissionPrompt": true
}

No prompt stated this would be saved, and there was no option to accept for the current session only.

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.167 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Why it matters

• Scope is part of consent. "Accept this risk?" is not the same as "Accept this risk permanently, on this machine, for all future sessions?" The prompt asks the former and performs the latter.
• Highest-risk gate. Bypass mode runs every action with no classifier. The more dangerous the gate, the more its default should favour narrow, re-confirmed scope — not the stickiest one.
• Defeats the warning's purpose. The warning's value is interrupting the user each time they cross the line; silent one-and-done persistence means one click governs indefinitely, often forgotten.
• Discoverability. The persisted flag lives in a settings file users rarely open, so the grant is effectively invisible and hard to knowingly revoke.

Precedent: the scoped pattern already exists in this tool

The separate "edit its own settings" permission prompt already offers session-scoped consent — e.g. "Yes, and allow Claude to edit its own settings for this session." The Bypass Permissions warning is simply inconsistent in not offering the same session-vs-always choice, so the preferred fix is an alignment, not a new pattern.

Suggested fix

• Minimum (accuracy fix — resolves the bug, no behaviour change): change the prompt copy to disclose that acceptance is persisted.
• Preferred (enhancement): replace the binary with explicit scope:

```
❯ 1. No, exit

1. Yes, for this session only
2. Yes, and don't ask again on this machine

``
Default to session-scoped; only option 3 writes skipDangerousModePermissionPrompt: true`.

Related issues

• #25503 — raises the silent persistence of skipDangerousModePermissionPrompt from a different angle (asks that --dangerously-skip-permissions skip the dialogue without needing the persisted setting; notes the persistence breaks git-synced configs). Complementary to, not a duplicate of, this report.
• #61465 — the settings-file re-serialization / key reordering triggered when this flag is written is already tracked there; out of scope for this issue.