Verboo Code: how to track background tasks with /tasks

You start a build, open another file and keep working. Half an hour later you cannot remember what you left running, or whether it is still going. /tasks is the panel that answers this inside Verboo Code: what is active right now, in which state, and which key stops whatever is stuck.

This guide covers the command, the panel keys, the file where output lands and the most common reason a task looks frozen. Everything checked against the verbeux-ai/code source, version 0.15.41, on 2026-11-13.

What does /tasks show?

Only tasks that are still running or queued. A task that finished, failed or that you stopped leaves the list immediately, even if you open the panel one second after it ends.

The filter is explicit in the code (src/tasks/types.ts): only entries with status running or pending make the list. The panel header summarizes the total as 2 agents · 1 active shell · 3 active agents, and each row shows the status plus the most recent activity for that task.

Which task types appear?

The panel groups them by section, and each type comes from a different place:

Type	Where it comes from	What the row shows
Shell	long command sent to the background	the command that ran
Local agent	subagent launched in the background	the task description
Remote session	cloud session	the session title
Team agent	agent running in the same process	the agent @name
Workflow	workflow running in the background	the workflow summary
Monitor	Monitor tool watching a log	the description of what is being watched

Team agents are grouped by team, leader on top and each member below. It is the same list that feeds the footer indicator, the one that shows 1 shell or 2 local agents while you type.

How do you open the panel?

Type /tasks at the prompt. The command also answers to the alias /bashes, a leftover from when only shells existed.

/tasks

With a single active task, the panel skips the list and opens that task's detail directly. With none, it shows No tasks currently running. The panel reads the current session state, so it never shows a task from another one of your sessions.

Which keys work inside the panel?

There are few, and all of them are on screen:

Key	Action
↑ / ↓	move the selection
Enter	open the task detail
x	stop the selected task
f	enter the team agent view
← or Esc	close the panel
ctrl+x ctrl+k	stop every running local agent

x only shows up when the selected task is actually running. In the detail view you get the accumulated output and the live status, without leaving the panel.

How do you send a task to the background?

Two ways. From the keyboard, with a command running in the foreground, ctrl+b sends it to the background and gives the prompt back. From the agent side, the same happens when it calls Bash with run_in_background: true, or launches a subagent or a Monitor.

sleep is the one command the code excludes from automatic backgrounding (src/tools/BashTool/BashTool.tsx): whoever asks for a pause wants the pause, not a loose process. If you ask explicitly, it goes to the background like anything else.

One variable turns the whole feature off: with CLAUDE_CODE_DISABLE_BACKGROUND_TASKS set, the run_in_background parameter is not even in the tool schema, and ctrl+b stops responding.

Where does each task's output go?

Every task writes to a <taskId>.output file, inside tasks/ in the project temp folder, in a per-session directory. The path shows up in the tool result and comes back in every completion notification, so pointing Read at it is enough.

/tmp/claude-{uid}/{project}/{sessionId}/tasks/{taskId}.output

The file stays on disk after the task ends. That is why the path is worth keeping: once the task leaves /tasks, the file is the only place the output still lives. The TaskOutput tool still exists, but it is marked deprecated in the code, specifically in favor of reading the file directly.

Why did the task freeze waiting for input?

Because the command asked for an interactive confirmation and there is nobody to answer. A background command receives no input, so a (y/n) in the middle of the run leaves the process parked forever.

Verboo Code detects this. A watchdog checks the output file size every 5 seconds and, if it does not grow for 45 seconds and the last line looks like an interactive prompt ((y/n), [Y/n], Press Enter, a question ending in ?), it fires a notification saying the task appears to be waiting for input.

The fix is to stop the task with x and run it again with the answer piped in, or with the program's non-interactive flag:

echo y | npm run db:migrate

The same applies to installers, cloud CLIs and anything that opens a menu. When in doubt, run the command once in the foreground before sending it to the background.

Is it worth leaving a task in the background?

It is when the task is long and needs no decision from you midway: test suite, build, dependency install, migration. You get the time back and a notification at the end.

It is not worth it for anything that asks for confirmation, for anything that depends on an environment variable that only exists in your interactive shell, or for a command that prints a lot: the output file is capped at 5 GB, and past that writing stops.