Letting work run in the background

You don't need a special mode

Ask naturally. A long command also promotes itself: anything still running after sixty seconds moves to the background instead of being killed, and you get told that it did. Nothing times out silently.

The board

/bg                    what's running and what finished
/bg output <id>        the captured log
/bg stop <id>          cancel one
/bg clear              clear finished entries

When something finishes, a notice appears in the conversation the moment it happens — you don't have to poll.

Why this matters

The usual failure is a two-minute test suite hitting a thirty-second tool timeout, and the agent concluding the tests "hung". Here the suite runs to completion, the output is captured whole, and the agent reads the real result.

Long builds, terraform apply, a watch-mode compiler, tail -f on a deploy — all the same shape.

The agent can start background work itself

Mid-conversation, if a subtask can proceed independently, it can dispatch it to the background and carry on with the rest. You'll see it appear on the board.

Background work versus background agents

Two different things that both keep running while you type:

• Background work is a command — a build, a server, a watcher. Covered here.
• A background agent is a coder with its own task, its own worktree, and its own diff. See Handing work to an agent.

If it doesn't work

It finished but I never saw output. /bg output <id> has the whole log, including for tasks that have already completed.

It's still listed as running after it exited. Processes that detach from their parent can outlive the tracking. /bg stop <id> clears the entry.

I closed the terminal and lost the server. Background commands belong to the session. Background agents survive, because they're owned by a shared daemon.

Next

• Handing work to an agent
• Running a whole goal in parallel
• Every command