Permission prompts loop in multi-agent sessions: Tool(*) allow form silently dead, prompts on harness-generated tool-result files, no propagation to running subagents
Status Open
Maintainer reply None cached
Activity 0 comments · opened Jul 24, 2026
Summary
Multi-agent (background subagent) sessions generate endless "Allow this bash command?" dialogs despite maximally-permissive settings, and the permission system offers no way to manage running agents. Filed on behalf of a Max user running large autonomous fleets.
Defects observed (single session, macOS Darwin 25.6.0, VSCode extension)
Tool(*)allow-rule form is silently ignored. Projectsettings.jsoncarried"Bash(*)","Read(*)", etc. inpermissions.allowfor months (documented as the grant-everything form in older guidance). The engine apparently only honors bareBash/Bash(prefix *)forms. No validation warning, no schema error — the rules just never match, so the user is re-prompted for commands they believe they granted long ago. Malformed permission entries should WARN loudly (doctor/lint on load).
- Prompts fire for the harness's OWN artifacts. Subagents extracting sections from persisted tool-result files (
~/.claude/projects/<proj>/<session>/tool-results/mcp-playwright-browser_evaluate-<ts>.txt) viased -n '/.../p' <file>trigger permission dialogs — even thoughsedwith read-only expressions is supposedly auto-validated. Because filenames are timestamped, per-command "Yes, allow for this project" approvals never stick, producing an infinite prompt loop. Reads of harness-generated files inside~/.claude/projects/should be implicitly permitted.
- Settings changes don't propagate to running sessions/subagents. After repairing the allowlist mid-session, already-running background agents kept prompting (they hold the permission snapshot from spawn time). There is no way to re-permission a running agent — the only options are (a) keep answering dialogs or (b) kill the agent and lose in-flight work. A reload-permissions mechanism (or live re-evaluation) is needed.
defaultMode: "bypassPermissions"in project settings did not suppress these prompts for subagent Bash calls in this environment — unclear interaction with the session-selected permission mode; either honor it or surface why it is being overridden.
Impact
Autonomous multi-agent work (the main value of background agents) is interrupted dozens of times per hour; the human operator becomes a click-through machine, then force-kills mid-deploy agents out of frustration — which is how half-deployed states happen.
Suggested fixes
- Lint/validate
permissions.allowentries and warn on never-matching forms likeBash(*). - Auto-allow reads of files the harness itself persisted under the session directory.
- Propagate settings changes to running sessions, or provide
/permissions reloadreaching subagents. - Document precedence between session permission mode and
defaultModein settings.