claude-code - 💡(How to fix) Fix Feature request: allow named subagents to surface permission prompts to the parent terminal in non-blocking mode [1 comments, 2 participants]

Summary

Currently, Claude Code users have to choose two of these three:

• Specialized named subagent (custom system prompt, tools, model)
• Non-blocking execution (parent can keep working)
• Permission prompts surface to the user instead of auto-deny

The three combinations available are documented in https://code.claude.com/docs/en/subagents:

The relevant doc text:

When fork mode is enabled, every subagent spawn runs in the background regardless of the `background` field. Forks still surface permission prompts in your terminal as they occur; named subagents auto-deny anything that would prompt, as described above.

Use case

When dispatching multiple named subagents in parallel for different specialized tasks, with fork mode on:

• Forks bubble prompts but lose the named subagent's custom system prompt and tools
• Named subagents preserve their config but auto-deny anything not pre-allowlisted

This forces a choice between pre-allowlisting every conceivable command (broad attack surface) or accepting silent denials when an unanticipated permission is needed mid-run. Debugging "why did my background subagent silently fail?" becomes a recurring friction point.

Proposed solution

A permission mode for named subagents, or a per-call flag on the `Agent` tool, that:

• Runs the named subagent non-blocking (concurrent with the parent)
• Routes permission prompts back to the parent's terminal
• Includes the subagent's identity and the specific tool call in the prompt UI so the user has context to decide

For example:

```typescript Agent({ subagent_type: "my-specialized-agent", prompt: "...", run_in_background: true, permission_mode: "ask" // or a new field: bubble_prompts: true }) ```

The UI design challenge is real — multiple concurrent prompts need queueing or stacking — but the value is high: parallelism + specialized subagent behavior + approval instead of silent failure.

Workarounds tried

• Pre-allowlisting common patterns: works but encourages broad rules over least-privilege
• Foreground subagents: block the parent, defeating parallelism
• Forks: lose the specialized system prompt and incur a higher token cost from inheriting full parent context

Verified empirically

Tested in Claude Code v2.x with `CLAUDE_CODE_FORK_SUBAGENT=1`:

• Fork (no `subagent_type`) + non-allowlisted `mkdir`: prompt bubbled to terminal, user could approve, command succeeded.
• Named subagent + `run_in_background: true` + non-allowlisted `mkdir`: auto-denied with "Permission to use Bash has been denied", subagent reported failure.

Both runs were dispatched from the same parent session with identical fork mode and permission settings. The behavior difference is solely in the named-vs-fork distinction.