Background tasks

An agent can leave work running after it has answered: a dev server, a long build, or a sub-agent working on its own. OAR calls this a background task. The task panel above the composer lists these tasks, lets you stop each one and open a command's output, and the agent's report on a finished task arrives as a reply of its own.

What counts as a background task #

• A shell command the agent left running, such as a dev server or a long build. Added in 0.9.12 On Grok, every command that runs longer than two seconds.
• A sub-agent working in the background. Sub-agents have their own page; here they are one more row in the panel.
• A monitor and, on Claude, an Ultracode workflow (see Ultracode workflows).

When the agent has answered and only such tasks are left, the conversation is no longer running a turn, but it is not idle either. Other agents see this as the state background_only (see How other agents see it). You see it as the task panel, which stays up as long as a task runs. The conversation list shows it by the title's colour: a session with a turn or background work running keeps the bright green title (see What a row shows).

The task panel #

The panel sits directly above the message box. It is folded to one line, such as 2 background tasks running, with a spinner while tasks run, and · 1 finished when finished commands are listed. Click the line to open the list. The panel is hidden when there is nothing to show, and the list scrolls when it holds more rows than fit.

Each row shows:

A running row has no separate state label: a task in the panel is running. A sub-agent leaves the panel when it ends; a shell command or monitor can stay for an hour as a finished row. After Stop the button reads Stopping… until the panel's next update, for up to 15 seconds.

On Copilot's SDK engine, a shell has no Stop button when the Copilot runtime cannot list its background tasks. Such a shell you can only end with Kill session (see What ends a task).

Preview cards live in the same panel and sit above the tasks. See What you see. A preview keeps the panel open after the task that started its server has ended.

The task console Added in 0.9.12 #

Click the description of a shell command or a monitor in the panel and its console opens: the command's output, so you can see what a build, a dev server or a test run is doing without asking the agent. It fills the screen on a phone. Added in 0.9.13 On a wider screen it ends above the task's row in the panel, so the row's test chip, clock and Stop stay in view and live beside it. Escape, ×, a click outside it or the back button close it.

• The last 2,000 lines show when it opens, and new output follows live. Scrolled up, you stay where you are, and Jump to end ↓ takes you back.
• Load earlier at the top pages back through the whole log, up to 2,000 lines at a time, until about 5 MB are loaded. Past that the button reads older output not loaded. Added in 0.9.13 The console's header has the same button whenever there is earlier output, so it is in reach while you follow the end of a long log.
• Progress bars that redraw one line show only its last state, and a line repeated several times in a row shows once with ×N.
• Colours stay, so a red failure is still red. Added in 0.9.13 Inverse text swaps its colours, so vitest's RUN, PASS and FAIL badges show filled. Other control codes are dropped, and a line is cut at 4,000 characters.
• Credentials are blanked: tokens and keys of the usual shapes, Bearer and Basic headers, a password in an address, and a value after a name such as API_TOKEN= or password: read [redacted]. Added in 0.9.13 So do the password of curl -u name:password, the values of --password, --token and --secret, mysql -p…, docker login -p, sshpass -p, redis-cli -a, an AWS secret access key, a Slack webhook path, ?key=, &sig= and &token= values in an address, and an Authorization header with any scheme. A reference such as $API_TOKEN or $(cat ~/.token) is left alone. The task rows in the panel are cleaned the same way: a task's description, summary and activity line.

The header names the task, its kind (Shell or Monitor), the time it has run and whether it is running, completed, stopped or failed, exit code 1, or Added in 0.9.13 waiting for its worker after the relay restart (see After a relay restart). It carries the quiet hint and the test-run chip too, and its own Stop while the task runs.

Agents on this or another relay can read the same output with read_task_output. What each provider offers is in By provider.

Quiet tasks #

A running shell command or monitor that has written nothing for a minute or more says so on its row and in its console header: no output for 12 min. From Settings → General → Mark a background task as quiet after on, the hint turns amber. That is 10 minutes by default, 1 to 120 minutes, and applies to every browser on the relay.

Quiet is not stuck: some steps print nothing for a long time. Open the console to see the last lines, then wait, raise the setting, or Stop the task. The relay looks at the output every 10 seconds, so the hint can lag by that much.

Commands piped into tail Added in 0.9.13 #

A command piped into tail, such as npm test 2>&1 | tail -40, writes nothing until it ends: tail keeps the last lines back until then. Its console would look stuck. When the task's command line shows such a pipe, the console marks where the output stops, until more output comes or the task ends:

Output stops here: this command pipes into tail, so the rest arrives when it ends.
Logging to a file instead (> run.log 2>&1) and following that file shows it live.

The row's no output for N min hint says the same on hover. tail -f and head pass lines on as they come and are not marked. To watch a run live, ask the agent to log to a file (> run.log 2>&1) and follow that file.

Claude, DeepSeek, Copilot and Grok report a shell task's command line for this. The relay blanks credentials in it, as in the output, and keeps its first 2,000 characters. A session whose agent started before the update to 0.9.13 reports none.

Test runs #

When a command's output looks like a test run of vitest, Playwright, node:test, jest, pytest, or turbo (also when started through pnpm), its row and its console header show a chip with the counts: ✓ 412 ✘ 2 when tests failed, in red, or ✓ 38 when none did. Hover the chip for the runner and the passed, failed and skipped counts. The counts follow the run while it goes. Added in 0.9.13 A run still going is counted over its whole log, however long, read on as it grows, so the chip keeps every test while the output grows past what the console shows. Once the runner prints its closing summary, that decides.

In the console, the chip and the first failure button beside it, shown when tests failed, jump to the first failing test in the loaded output. If it lies in older output, the console says so; Load earlier brings it in.

Finished commands #

A shell command or monitor whose output the relay reads from a file stays in the panel for an hour after it ends, as a dimmed row: ✓ when it completed, ✘ when it failed, ■ when it was stopped, Added in 0.9.13 ? when the relay cannot know how it ended (After a relay restart), with how long it ran and its test chip. Its console still opens, so you can read why a run failed after the agent has moved on. × hides the row until you reload the page. At most 20 such rows are kept per conversation. Added in 0.9.13 They survive a relay restart (see After a relay restart).

When a task finishes #

When a task ends, it leaves the panel, or a command stays as a finished row. The agent is woken, looks at the result and answers. That answer is a continuation reply: it is not an answer to a message of yours, and its header carries a background continuation badge. You can read it like any other reply.

A continuation is a reply like any other for notifications, so a device that notifies you when a turn finishes does that here too (Turn completed in Settings → Notifications). An agent that watches the session gets a task_finished or task_failed event instead (see How other agents see it).

If a relay restart comes between the end of a task and its continuation, the continuation is dropped, not run again. See Restarts and resume.

Ultracode workflows #

Ultracode workflows are a Claude feature. The panel shows one as a Workflow row with a chevron. Open the chevron to see the progress tree.

• Phases are headers, and the agents of the workflow sit under them.
• Each agent shows a state icon (○ queued, ◐ running, ✓ done, ✗ failed or killed), its label, and a line with the model, the tokens, the number of tool calls, the time and, after a retry, attempt 2. A running agent adds the tool it is using.
• Log lines, the last five, stand above the phases.
• A tree longer than 100 agents ends with +N more agents.

The tree is open while the workflow runs and folded once it has settled. A choice you make with the chevron is kept while the row is in the panel. While the workflow runs, the tree may lack phase titles and log lines; the final tree has them.

When the workflow ends, the reply that sums it up keeps a folded card in the transcript:

🧩 Finished background task — review-shared-modules · 20 agents · 1.2M tok · 28m

Open it for the final tree. Fields that are not known are left out, and a workflow that did not complete says how in brackets, as in Finished background task (failed), or (unconfirmed) when the outcome never arrived. The card is saved with the reply and stays after a reload.

Background task timeout #

Settings → General → Background task timeout sets how long background tasks alone may keep a session running after its reply. It is a slider from 0 to 10 hours in 5-minute steps. The default is 4 hours. 0 means no limit: tasks then run until they finish or you stop them.

When the time is up the relay stops the tasks, and the agent reports on it in a continuation reply as for any task that ends. On Claude and DeepSeek the clock counts only while nothing but tasks keeps the session going, and starts again from zero whenever a turn runs in between. On Copilot's SDK engine each task has its own clock, which starts when that task starts. How it sits among the other timers is on Turns and the queue.

What ends a task #

After a relay restart Added in 0.9.11 #

A worker that keeps running across a relay restart keeps its tasks, and the relay asks it for them again on the worker's next heartbeat. They come back in the panel with their original start time, so the session reads as still working: Suspend host waits for them, and a watching session is not told all_idle. A task that ended while the relay was away still reports its end.

A session whose worker was started before the update to 0.9.11 cannot answer that question yet. It shows one row, background work, details not reported since the relay restarted (Kill session in its ⋯ menu ends it), until it reports a change. For the first 45 seconds after the relay starts, a suspend also waits for sessions that have not reported yet.

Added in 0.9.12 The consoles of the tasks that come back open again, with the whole log, and a quiet hint shows again once the relay has looked at the output.

Added in 0.9.13 The relay keeps the console rows in its database, so the consoles survive the restart too:

• Finished rows come back with their ✓ or ✘ for the rest of their hour.
• A running command's console reads its output at once, before its worker has reported. Until the worker says the command still runs, the console says it is waiting for its worker and has no Stop.
• A command whose worker did not come back (it went down with the relay, for instance at a reboot) is marked finished after about a minute and a half, never as running again. The relay cannot know how it ended, so its row shows a neutral ? instead of ✓ or ✘, titled ended, result unknown. Its output stays readable for the rest of the hour.

Commands that ran before the update to 0.9.13 have no stored row; they come back when their worker reports, as above.

Under the Linux service a restart stops the workers, and their tasks with them; see What a restart keeps.

How other agents see it #

list_sessions and read_session give each session a state: running_turn, background_only (the agent has answered, background work still runs) or idle. They also list its tasks, the background agents and shell tasks, with when each started, when it last did something, how it ended and the exit code where that is known. A session with only background tasks therefore does not read as inactive. Added in 0.9.12 On Copilot's SDK engine a finished task reports completed, failed or stopped, a shell its exit code, and a sub-agent its result (or its error) as the summary; before, such tasks ended as unknown.

An agent that watches the session can be woken by the events task_finished and task_failed, each with the task's description, outcome and summary. A task that was stopped, or that exited with a non-zero code, counts as failed. It can ask for task_started too. Added in 0.9.13 By default a watcher hears of a sub-agent that finished and of every task that failed, but not of a shell command or monitor that ended well; it names task_finished to get those.

Added in 0.9.12 read_session also gives each task its taskId, whether it has output to read, and for a command its quiet time and test counts. Added in 0.9.13 It also gives a shell task's command line, where the provider reports it. A task's description, summary, last tool call and command line have their credentials blanked, as in the console. read_task_output then reads the end of that output, cleaned like the console's.

By provider #

The Ultracode tree and the Finished background task card exist on Claude only. The full capability table is on Providers at a glance.