bypassPermissions confirmation dialog has no pre-accept flag; blocks headless/autonomous sessions

[ph47s74x]

Summary

defaultMode: bypassPermissions in settings.local.json triggers a one-time interactive confirmation dialog ("WARNING: Claude Code running in Bypass Permissions mode … 1. No, exit / 2. Yes, I accept") that cannot be pre-accepted. This makes bypassPermissions effectively unusable for headless / autonomous / spawned-from-script sessions, even though those are precisely the contexts where it's most needed (multi-session orchestration, choir-style swarms, scheduled agents).

By contrast, workspaceTrust has the well-known precedent hasTrustDialogAccepted: true in ~/.claude.json projects[] that lets callers pre-accept trust without an interactive dialog. There is no analogous pre-accept key for bypassPermissions.

Repro

1. .claude/settings.local.json:

   {"permissions": {"defaultMode": "bypassPermissions"}}

2. Spawn claude detached (e.g. via screen, nohup, or in my case choir spawn into a headless GNU screen window).
3. Session parks at:

   WARNING: Claude Code running in Bypass Permissions mode
     o 1. No, exit
       2. Yes, I accept
     Enter to confirm · Esc to cancel
   

4. screen -X stuff with arrow-key sequences to accept the dialog is brittle and in my case exited the session instead of accepting (the "No, exit" option is the default).

Expected

A durable, declarative way to pre-accept bypass mode without human interaction. Options:

1. Best: a per-project / per-user key matching the hasTrustDialogAccepted pattern, e.g.

   "hasAcceptedBypassPermissionsMode": true

   in ~/.claude.json projects[], honoured when defaultMode: bypassPermissions is in effect.
2. Alternative: make --permission-mode=bypassPermissions on the CLI suppress the confirmation dialog (it already accepts the risk implicitly by setting the flag). Today it still shows the dialog.
3. Alternative: make --dangerously-skip-permissions (which already suppresses the dialog) respect per-session overrides from settings, so it can be configured per-cwd.

Why this matters

The marketing case for bypass mode is autonomous agents in sandboxes — that is the exact case where no human is sitting there to dismiss a dialog. Multi-session frameworks (choir, custom swarm runners, CI-driven batch sessions) need this to work without TTY puppetry. Today the only reliable workaround is passing --dangerously-skip-permissions via a wrapper, which requires every orchestration tool to re-implement the same flag forwarding.

Environment

• Claude Code v2.1.117
• Windows 11 + WSL2 Ubuntu, GNU screen backend
• 21 choir-spawned peers, all blocked at the dialog simultaneously

[github-actions]

Found 3 possible duplicate issues:

1. [BUG] --dangerously-skip-permissions flag should bypass the permissions mode dialog without requiring persisted setting #25503
2. Feature request: non-interactive/headless mode for skills (CLAUDE_NONINTERACTIVE) #42788
3. Desktop app: bypassPermissions mode still prompts for confirmation #42975

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

[github-actions]

This issue has been automatically closed as a duplicate of #25503.

If this is incorrect, please re-open this issue or create a new one.

🤖 Generated with Claude Code

[github-actions]

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.