Run long subagents in the background and keep working

The audits so far were quick enough that watching them finish cost you nothing. But the next slice isn’t: you want a subagent to run the full integration suite against the reconcile job and report which ledger writes break under load — minutes of churning, not seconds. Sitting and watching a progress spinner for that is dead time. This is where the foreground-versus-background distinction earns its place.

Two ways a subagent runs

Every subagent runs one of two ways, and the difference is simply whether it blocks you:

• Foreground subagents block the main conversation until they finish. Everything so far has been foreground — you spawned the worker and waited. Permission prompts pass straight through to you as they come up.
• Background subagents run concurrently while you keep working in the main thread. They report back when done, but they don’t hold you hostage in the meantime.

Claude decides which to use based on the task, but you can force the issue. Ask for it in words, or use the shortcut — Ctrl+B backgrounds a running task. Both are documented under run subagents in foreground or background.

> run the integration suite against the reconcile job in the background and
  report which ledger writes fail under load

  ⏵ Agent (general-purpose)  reconcile load test   ▶ running in background

> # your prompt is free immediately — keep going while it churns
> meanwhile, draft the migration note for the charge path

You’re back at the prompt instantly, working on the migration note, while the load test grinds away in its own context somewhere behind you. When it finishes, its result surfaces as a message in your conversation.

The catch: background subagents can’t ask you anything

There’s one behavior here you must internalize, because it’s the difference between a background subagent that works and one that silently stalls. A foreground subagent that hits a permission prompt asks you and waits. A background subagent cannot — you’re off doing something else, so there’s no one to answer. Per the docs, background subagents run with the permissions already granted in the session and auto-deny any tool call that would otherwise prompt. If one needs to ask a clarifying question, that call fails and the subagent carries on without the answer.

The practical consequence: background work only goes smoothly when the permissions it needs are already granted before you send it off. If the load test needs to run a command that isn’t pre-approved, it’ll get auto-denied in the background and come back having quietly skipped it. This is where the Permissions & modes chapter pays off — pre-approving the command patterns a background job needs is what lets it run unattended. And if a background subagent does come back short because it got denied something, the docs note the clean recovery: start a new foreground subagent with the same task so the prompts surface interactively and you can grant what it needs.

Checking on it and killing it

Background work you can’t see is background work you’ve lost track of, so there’s a panel for it. The /tasks command lists everything running in the background of the current session and lets you check on, attach to, or stop each one — that’s the canonical control surface, documented in run agents in parallel. The /agents command’s Running tab similarly shows live subagents and lets you open or stop them.

> /tasks
  ▶ reconcile load test    running    4m12s    attach · stop

Attaching pulls you into the subagent’s transcript to watch or steer; stopping kills it. The whole point of backgrounding was to stop watching — but /tasks means you never lose the ability to look, or to pull the plug if a worker is clearly off the rails and you don’t want to pay for it to finish.

You now have the full range of how a subagent runs: one or many, foreground or background, watched or walked-away-from. But every subagent so far has been ad hoc — you described the ledger audit fresh each time. That audit isn’t a one-off; it’s a job you’ll run before every migration. Next we make it reusable, so it always runs with the same tools, the same instructions, and the same shape.