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)

  1. Tool(*) allow-rule form is silently ignored. Project settings.json carried "Bash(*)", "Read(*)", etc. in permissions.allow for months (documented as the grant-everything form in older guidance). The engine apparently only honors bare Bash / 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).
  1. 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) via sed -n '/.../p' <file> trigger permission dialogs — even though sed with 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.
  1. 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.
  1. 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.allow entries and warn on never-matching forms like Bash(*).
  • Auto-allow reads of files the harness itself persisted under the session directory.
  • Propagate settings changes to running sessions, or provide /permissions reload reaching subagents.
  • Document precedence between session permission mode and defaultMode in settings.

View original on GitHub ↗