[FEATURE] Let users default the Agent tool's run_in_background to true (and/or flip the default), so dispatching a subagent doesn't silently block the parent session

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Priority: High - Significant impact on productivity
Feature Category: Configuration and settings

Problem Statement

When the model dispatches a subagent via the Agent tool, the run_in_background parameter defaults to false (foreground). A foreground Agent blocks the parent session synchronously: the parent — and the human watching it — is frozen until the subagent returns. For long or independent subagent work, that stall is pure waste, and it's especially painful when several sessions are open at once and each one blocks on its own foreground dispatch.

The safe choice (run_in_background: true) frees the parent immediately, but it has to be passed explicitly on every single Agent call. So avoiding the stall depends entirely on the model remembering to set the flag — and the more dangerous behavior (a silent, blocking parent) is the omitted-value default, i.e. the easiest thing to forget. The failure mode of the current default (parent silently stalls, sometimes for a long time) is worse than the failure mode of background (results simply arrive asynchronously).

Critically, there is currently no way for a user to change this default:

• There is no settings.json key or environment variable for it. (disableAgentView turns the whole feature off; agent picks a default named subagent; --bg / /background govern the main session, not the Agent tool's parameter.)
• Hook-based workarounds aren't reliable: a PreToolUse hook that injects the flag via updatedInput is not honored by the Claude Code desktop app, so on desktop there is no mechanical way to set this default at all — avoiding the stall is left entirely to the model's memory.

Net effect: the risky option is both the default and the hardest to enforce.

Proposed Solution

Give users a way to make background the default for Agent-tool dispatches. Either of the following would solve it (both acceptable; listed in order of preference):

(b) A settings.json key (opt-in, no behavior change for anyone who doesn't set it). For example:

{
  "agentDefaultRunInBackground": true
}

When set, an Agent call that omits run_in_background is treated as run_in_background: true. This must work on the desktop app too (the place where hook-based workarounds currently don't apply).

(a) Alternatively, flip the Agent tool's run_in_background default to true — at minimum for long-running / independent dispatches — on the grounds that a silent blocking stall is a worse default failure mode than asynchronous results.

Honest caveat: a blanket flip of (a) for every dispatch isn't strictly free — there are legitimate cases where you want to block and consume the subagent's result inline before continuing (e.g. a quick lookup whose answer you need now). That trade-off is exactly why the user-configurable setting (b) is the safer primary ask: it lets people who run lots of parallel/long dispatches opt into the non-blocking default without changing behavior for those who rely on foreground. A middle option would be to keep the tool default as-is but make the model's guidance bias toward background for clearly independent/long work.

Alternative Solutions

Workarounds tried, and why they fall short:

• Passing run_in_background: true explicitly on every Agent call — works, but depends on the model remembering every time; the omitted default is the dangerous one.
• A PreToolUse hook injecting the flag (updatedInput) — not honored by the desktop app, so it can't establish the default there.
• disableAgentView / --bg / /background — none of these set the Agent tool's per-dispatch background default (see Problem Statement).

None of these give a durable, desktop-working way to make "don't block the parent" the default.

Use Case Example

1. I have two or three Claude Code sessions open, each doing independent work.
2. In one session the model decides to dispatch a subagent for a long, self-contained task (a broad search, a migration, a multi-file audit).
3. Because run_in_background defaults to false, that session freezes until the subagent finishes — I can't steer it, and if I'm not watching, it just sits there. Meanwhile I'd happily have let it keep going and collected the subagent's result when it landed.
4. With a setting (or a background-leaning default), the dispatch would return control immediately and notify me on completion, so none of the parallel sessions stalls on a dispatch I never needed to block on.

Additional Context

• This is about the model-facing Agent tool's run_in_background parameter, which is distinct from the user-facing --bg flag / /background command (those send the main session to the background; they don't set the Agent tool's default).
• I checked the settings reference: there is currently no key for this default.
• The desktop-vs-CLI gap matters here: hook-based defaulting works (at best) only on the CLI, so a first-class setting is the only mechanism that would also work on the desktop app. (cf. #67197 on CLI/desktop agent-management inconsistency.)
• Related but different: #68586 (Agent tool output_mode) touches the same tool surface but addresses how results enter context, not the background default.