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

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:

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

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

```
WARNING: Claude Code running in Bypass Permissions mode
o 1. No, exit

1. Yes, I accept

Enter to confirm · Esc to cancel
```

1. 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.

``json
"hasAcceptedBypassPermissionsMode": true
`
in ~/.claude.json projects[<path>], honoured when defaultMode: bypassPermissions` is in effect.

1. 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.
2. 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