Foreground vs Background Subagents in Claude Code: When Concurrency Helps and When It Hurts

Reference

One of the easiest ways to make Claude Code feel faster is to let subagents work in parallel.

One of the easiest ways to make it feel worse is to do that on the wrong task.

Claude Code subagents run in their own context windows with their own prompts, tool access, and permissions. Those subagents can run either in the foreground or in the background. Foreground subagents block the main conversation and can pass permission prompts and clarifying questions back to you. Background subagents run concurrently, inherit only the permissions approved up front, auto-deny anything else, and cannot pause to ask clarifying questions mid-run.

The practical rule is simple:

Use foreground when the task is interactive, ambiguous, or likely to hit permission friction. Use background when the task is self-contained, noisy, and easy to summarize.

The real difference

Foreground subagents are the safer default. They block the main conversation until they finish — which sounds slower, but they can ask you questions and surface permission prompts as needed. That makes them better for work where the agent may need course correction before it touches code or runs commands.

Background subagents are about concurrency. Claude Code launches them while you keep working. You can also explicitly ask Claude to run a task in the background, or press Ctrl+B to background a running task. Background tasks run asynchronously, get a unique task ID, buffer their output, and Claude can retrieve that output later.

The downside that most people discover the hard way: a background subagent must be able to finish without you. Claude Code asks for the needed tool permissions before launch, then the subagent inherits those permissions and auto-denies anything not pre-approved. If it needs to ask a clarifying question, that tool call fails and the subagent keeps going. If it fails because of missing permissions, you can resume it in the foreground and retry interactively.

That tells you exactly when backgrounding is a bad idea.

When background subagents help

Background subagents shine when the work is independent, read-heavy or output-heavy, easy to summarize, and unlikely to require human judgment mid-run.

Large test runs

"Run the full test suite and summarize only the failures."

Nearly ideal. The task is noisy, mostly mechanical, and the final output is small.

Parallel codebase exploration

"Research auth, billing, and API modules in parallel."

This works because the investigations are independent and each can return a summary.

Log or documentation mining

"Scan these logs for recurring timeout patterns and summarize the likely causes."

Big input, compact answer — a strong fit.

When background subagents hurt

Ambiguous implementation work

"Refactor the auth flow to OAuth2."

This is not one task. It is ten tasks hiding inside one sentence. Claude's Plan mode exists for this kind of work because it can analyze read-only, ask requirements questions, and refine the direction before editing. Background execution skips all of that.

Tasks with likely permission friction

Anything that may touch secrets, shell commands outside normal allowlists, external systems, or sensitive files is a poor candidate for background execution. If the background subagent was not granted what it needs ahead of time, it will fail quietly.

Claude Code permissions can explicitly allow or deny tool patterns like Bash(npm run test *) or Read(./.env). If the task needs something outside those pre-approved patterns, the subagent auto-denies it and continues with degraded results — or stops.

Tasks that need iterative judgment

"Review this PR and decide whether the architectural direction is right."

That often needs follow-up questions and tradeoff discussion. Foreground is better.

Tasks that need nested delegation

Subagents cannot spawn other subagents. If your plan involves a manager subagent launching child subagents, that is not how this system works. For nested delegation, chain subagents from the main conversation, or use skills instead.

The simplest decision rule

Run a subagent in the background only if all four are true:

1. The task is self-contained
2. The task can succeed without asking you questions
3. The required permissions are obvious ahead of time
4. A summary is enough — you do not need step-by-step interaction

If even one of those is false, foreground is usually the better call.

A practical split that works

Use foreground for:

• planning a refactor
• writing or editing code
• debugging unclear failures
• architectural review
• tasks touching sensitive files or risky commands

Use background for:

• test execution
• repo-wide search
• docs lookup
• log analysis
• parallel module research
• anything noisy but bounded

Permissions are where most background runs break

A lot of people think concurrency is the hard part. It is not. The hard part is permissions.

Claude Code settings support explicit allow and deny rules for tools and patterns. Subagents also have their own tool restrictions. Built-in subagents like Explore are read-only and denied write and edit tools. When a background run fails, the cause is usually one of these:

• the subagent did not get the tool approval it needed before launch
• the parent session already denied the action
• the task implicitly needed a write or shell capability the agent did not have
• the task needed clarification, but background execution could not stop to ask

That is why background subagents are best for predictable operations.

What to do when a background subagent fails

Do not immediately rerun the same thing in the background.

First ask: why did it fail?

If the issue was missing permissions or the task needed back-and-forth clarification, move it to the foreground. A background subagent that fails because of missing permissions can be resumed in the foreground so it can retry with interactive prompts.

The clean recovery pattern:

• keep background for mechanical work
• resume foreground for judgment-heavy recovery

Hooks make this safer

Hooks add deterministic behavior around agent runs. Anthropic positions hooks as the right tool when you want rules to always happen, rather than hoping the model chooses correctly. Subagents can define frontmatter hooks during their own lifecycle, and project settings can react to SubagentStart and SubagentStop events in the main session.

Practical uses:

• validate shell commands before a subagent runs them
• run a linter after file edits
• do setup or cleanup when a specific agent starts or stops

This matters more for background runs because you have less interactive control once they are in motion.

One blunt recommendation

Most teams should not start with "parallel everything."

Start with one or two narrow background use cases — test runner, repo explorer, log analyzer — and keep implementation, planning, and risky changes in the foreground until your permission model and agent descriptions are solid.

Background subagents are great when the task is isolated and deterministic. They are bad when the task is fuzzy, political, and full of hidden edge cases — which describes a lot of real software work.

The real question is not "Can this be parallelized?"

The real question is:

Can this finish correctly without me?

If yes, background can save real time. If no, concurrency is just a nicer way to fail.

For the broader picture on subagents, skills, and when to combine them, see Claude Code Subagents for Developers: When a Skill Is Not Enough.