Background Tasks

Some commands are slow — a full test suite, a production build, a long-running dev server — and waiting idle for one to finish wastes the rest of the time a session could be making progress on something else. A background task starts the command, hands control back immediately, and lets you check on it (or get notified when it finishes) instead of blocking everything until it's done.

What this is for

• Long test suites or builds that you want running while other work — reading code, drafting an unrelated fix, addressing a different part of the same task — continues in parallel.
• Watch-mode processes (a dev server, a file watcher) that are meant to keep running in the background for the rest of a session, not finish and exit.
• Anything where the value is in the eventual output, not in watching it run — a deploy that takes several minutes, a data processing job.

How it differs from a subagent

This is an easy pair to conflate, but they solve different problems. A subagent is a separate reasoning agent with its own context, used to isolate a chunk of thinking and acting. A background task is a plain shell process — there's no separate agent reasoning about it, just a command running to completion (or indefinitely, for a long-lived process) while the main session moves on. You background a slow test run; you delegate a broad investigation to a subagent. They can combine — a subagent's work might itself include kicking off a background command — but they're not the same mechanism.

A typical pattern

1. Start the slow command in the background instead of waiting on it synchronously.
2. Continue with other useful work in the meantime — reviewing a different file, addressing a separate piece of feedback, investigating a related issue.
3. Check the background command's output once it's likely done, or get notified automatically when it completes.
4. Act on the result — fix what a failing build revealed, or confirm a long test run passed before considering the task finished.

What to avoid

Backgrounding something and then forgetting to ever check its result defeats the purpose — the point is parallel progress, not ignoring the outcome. A task isn't actually verified until its background output has actually been read, the same way a foreground command's output would be.

This closes out advanced features. The final section puts everything together: a real workflow from start to finish, and the habits that make all of this work well in practice.