Summary
Add a way to make the parent session's bypass permission mode propagate automatically to every session dispatched from agent view (claude agents) and to every subagent those sessions spawn — without having to set defaultMode: bypassPermissions per-directory or permissionMode per-subagent-frontmatter.
Motivation
When running many parallel background sessions via claude agents (intended exactly for unattended work), the current model forces a choice between:
- Manually configuring
defaultMode: bypassPermissions in every working directory's .claude/settings.json, or
- Manually adding
permissionMode: bypassPermissions to every custom subagent's frontmatter, or
- Dispatching from the shell with
claude --bg --permission-mode bypassPermissions ... (one prompt at a time, defeating the point of the agent-view dispatch input).
The dispatch input inside agent view itself has no way to express "run this dangerously" — per the docs:
Dispatching from the agent view input doesn't pass a permission mode, so the session uses the defaultMode from that directory's settings or the permissionMode from the dispatched subagent's frontmatter.
And per #40241, even when the parent session is already running with --dangerously-skip-permissions, that mode does not propagate to subagents spawned via the Agent tool. The user has to re-approve permissions for each subagent, which is exactly the friction the flag was meant to remove for unattended runs.
Proposed behavior
One or both of:
- A
propagatePermissionMode setting (or similar) that, when set with bypassPermissions, applies to: (a) sessions dispatched from agent view in that scope, and (b) subagents/Agent-tool invocations spawned by those sessions, transitively.
- A dispatch-input prefix or hotkey in agent view (e.g.
!!<prompt> or Shift+Ctrl+Enter) that dispatches the new session in bypassPermissions mode, mirroring how ! already prefixes Bash replies in the peek panel.
In both cases, propagation should be gated by the same one-time interactive acceptance that --bg --permission-mode bypassPermissions already requires, so the safety property of "user has affirmatively opted in to unattended bypass" is preserved.
Why this isn't an exact duplicate
Environment
- Claude Code v2.1.140 (agent view, research preview)
Summary
Add a way to make the parent session's bypass permission mode propagate automatically to every session dispatched from agent view (
claude agents) and to every subagent those sessions spawn — without having to setdefaultMode: bypassPermissionsper-directory orpermissionModeper-subagent-frontmatter.Motivation
When running many parallel background sessions via
claude agents(intended exactly for unattended work), the current model forces a choice between:defaultMode: bypassPermissionsin every working directory's.claude/settings.json, orpermissionMode: bypassPermissionsto every custom subagent's frontmatter, orclaude --bg --permission-mode bypassPermissions ...(one prompt at a time, defeating the point of the agent-view dispatch input).The dispatch input inside agent view itself has no way to express "run this dangerously" — per the docs:
And per #40241, even when the parent session is already running with
--dangerously-skip-permissions, that mode does not propagate to subagents spawned via the Agent tool. The user has to re-approve permissions for each subagent, which is exactly the friction the flag was meant to remove for unattended runs.Proposed behavior
One or both of:
propagatePermissionModesetting (or similar) that, when set withbypassPermissions, applies to: (a) sessions dispatched from agent view in that scope, and (b) subagents/Agent-tool invocations spawned by those sessions, transitively.!!<prompt>orShift+Ctrl+Enter) that dispatches the new session inbypassPermissionsmode, mirroring how!already prefixes Bash replies in the peek panel.In both cases, propagation should be gated by the same one-time interactive acceptance that
--bg --permission-mode bypassPermissionsalready requires, so the safety property of "user has affirmatively opted in to unattended bypass" is preserved.Why this isn't an exact duplicate
Environment