Background runs
Delegating a job to run outside the current conversation, and the run lifecycle.
Opening the drawer
The /background command opens a drawer showing the count of runs currently in progress across the workspace.
Explain how auth refresh works
Find and fix the failing test
Background tasks
Add input validation to the signup form
general · write allowed
Delegating a job
From the drawer, choose Delegate a job, pick a delegate, describe the job, and choose whether to wait for it or move on. Each delegate option states its write capability up front (what it's allowed to touch), so you know the blast radius before you commit to a run.
Run lifecycle
| State | Meaning |
|---|---|
| Queued | Waiting for a slot |
| Starting | Initializing |
| Running | In progress |
| Awaiting approval | Blocked on a permission decision |
| Awaiting a question | Blocked on an answer from you |
| Succeeded / Failed / Cancelled | Terminal |
A run blocked on a person (waiting for approval or an answer) releases its concurrency slot while it waits. It doesn't tie up a worker just because it's stalled on you.
Acting on a run
From a run entry you can:
- Cancel it.
- Open transcript: read-only. Mode, effort, and auto-approve controls are visible but disabled; it's not a conversation you're steering, only reading.
- Send a follow-up to it.
- Use result, which drops the run's output into your composer as a draft. It is never auto-sent: you still have to send it yourself.
- Dismiss it from the drawer.
Scope
Runs belong to the workspace, not to one conversation. The drawer lists every run in the workspace, with the current conversation's runs listed first. A run survives the panel being closed, hidden, or reloaded: that persistence is the point of delegating work in the first place.