claude-code - 💡(How to fix) Fix bypassPermissions confirmation dialog has no pre-accept flag; blocks headless/autonomous sessions [1 comments, 2 participants]

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[<path>] 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[<path>], 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