Claude Code Background Tasks for Client Work: Keep Building While a Long Command Runs

The Short Answer

When a command is going to take a while, a dev server you need running for the rest of the session, a full test suite, a large build, a data migration, tell Claude to run it in the background instead of waiting on it. The session stays responsive: you can keep prompting, keep reviewing other parts of the client's codebase, or start the next piece of work the client asked for, while the slow command runs behind the scenes.

The output does not disappear once it is backgrounded. You can ask Claude to check on it at any point, read whatever it has printed so far, and get flagged when it finishes or fails. What backgrounding does not do is make the command itself run faster, and it does not excuse you from actually reading the result before you tell a client the build passed.

What Counts as a Background Task

Anything that runs long enough that sitting and waiting on it is a worse use of a billable hour than doing something else. On client work that is usually one of a handful of shapes: a dev server you need alive for the rest of the session so you can keep testing changes against it, a full test suite that takes minutes instead of seconds, a production build, a database migration, or a long-running scrape or data job a client asked for as part of the build itself.

Short commands do not need this. If something finishes in a couple seconds, backgrounding it just adds a step of checking back on something that was already done by the time you asked. Reserve it for the commands where the wait is genuinely long enough to interrupt the flow of the session.

Checking On a Backgrounded Task

Once a command is backgrounded, ask Claude to check on it whenever you want an update, whether it is still running, what it has printed so far, or whether it finished and how. This is a pull, not a push, by default: Claude will not interrupt what you are doing to announce a background task finished unless you ask or the workflow you are running is set up to surface it. Build the habit of asking before you move on to something that depends on the result.

1. Before backgrounding something, know what 'done' looks like for that command, a specific exit status, a specific line in the output, so you are not guessing later whether it actually finished cleanly.
2. Check in on a long background task periodically rather than only at the very end, especially on a migration or a job that touches a client's live data. Catching a failure at the halfway point is cheaper than catching it after it has run to completion and failed anyway.
3. Before you tell a client or move on to the next step that depends on it, read the actual output. Do not report a result off a task you assumed finished because enough time had passed.

What Backgrounding Does Not Do

Backgrounding changes when you look at the output, not how long the command takes or what it does. A slow test suite is exactly as slow backgrounded as it is in the foreground. A migration that would fail against a client's schema still fails, it just fails somewhere you have to go check instead of somewhere you were staring at when it happened.

It also does not replace the review step. This pairs with the same discipline as [Claude Code checkpoints for client work](/blog/claude-code-checkpoints-for-client-work): moving faster through a session, whether that is a higher-autonomy approval mode or a backgrounded long-running command, only stays safe if you are still actually looking at the result before you call it finished. The convenience is in not having to sit and wait, not in skipping the check.

Why This Matters More on Client Work Than On Your Own Projects

On your own project, sitting and watching a build run is just dead time you lose. On a paid client session, that same dead time is an hour you are billing for while producing nothing, or an hour you are eating because it felt wrong to bill for watching a progress bar. Backgrounding turns that hour back into billable, useful work: you keep moving on the next item in scope while the slow command runs behind it, instead of choosing between charging the client for your idle attention or absorbing the wait yourself.

It also changes what a client session looks like from the outside. A client watching over your shoulder, or reading a session summary after the fact, sees continuous forward progress instead of a visible stall every time something slow needs to run. That is a small thing, but it is the kind of small thing that reads as competence on a call.

A Backgrounding Habit for Client Sessions

1. Background anything you expect to take more than roughly a minute and does not need your input partway through: dev servers, full test suites, builds, migrations, long data jobs.
2. Say out loud, even just to yourself, what a clean finish looks like before you background it, so checking on it later is a quick comparison instead of a fresh investigation.
3. Keep working on the next piece of scope while it runs. Do not just wait with the terminal open, that defeats the entire point.
4. Check the real output before you report a result to the client or move on to a step that assumes the background task succeeded. 'It has probably finished by now' is not verification.
5. If you are running more than one background task at a time, keep track of which is which. A vague check-in on 'the thing that was running' gets slower and more error-prone the more you have going at once.

Common Mistakes

1. Telling a client something passed or shipped based on a background task you never actually checked the output of.
2. Backgrounding a command that needs interactive input and then coming back to find it stalled at the first prompt, having done nothing the whole time you thought it was working.
3. Running too many background tasks at once and losing track of which one covers which part of the client's request.
4. Backgrounding something short enough that waiting on it directly would have been faster than the overhead of checking back later.

Inside the Claude Code Profit Room, builders trade the actual client sessions where a backgrounded task saved a billable hour, and the ones where skipping the check cost more time than it saved. It's $9 a month at https://www.skool.com/claudecodeprofitroom/about, come tell us what you background by default.