You can't tell if an agent's build, test, or dev server passed without asking it

[jamesondh]

Problem

I'd like to do almost all of my development from the mobile app, without opening a terminal. Most of that works well: I ask the agent, review the diff, and settle. The weak spot is anything that keeps running or produces a pass/fail result, like a dev server or a build.

• I can't see what a background command did. When the agent starts a dev server or build as a provider background shell, T3 Code shows its name ("Running: Start the shared dev server") but not its output or exit result. The agent may be woken when it exits. I can't see that from my phone except by asking it. The shell also ends on settle (fix(server): settle no longer leaves monitors and dev servers running #5774) and is cancelled on server restart, and each provider behaves differently.
• Running an action leaves no record. An action writes ${script.command}\r into a thread terminal (ChatView.tsx). There's no running/succeeded/failed state, exit code, stop, or restart. Reading scrollback on a phone is the only way to know whether a build passed.
• Hand-offs are common and hard to find. fix(clients): a dev server left running no longer says the thread is waiting #15114 found that "every dev server left at the end of a turn was a hand-off to the user," and those servers ran for 2 to 24 hours. [Bug]: The sidebar doesn't show a thread's running dev servers: the per-thread indicator exists only in the legacy sidebar and never counts servers the agent started #15238 notes the default sidebar doesn't show them.

Building on #8714

#8714 lets agents list, run, and stop saved project scripts in terminals they own, without passing raw command text. This proposal is the follow-up that gives those runs, and user-started actions, a result that every client can show.

Most of the rest exists too:

• ProjectSetupScriptRunner already wraps setup scripts in an exit-code marker and gets a real status, duration, and output.
• TerminalManager reports hasRunningSubprocess, persists history, and keeps busy terminals open on settle.
• PortScanner links a listening port to { threadId, terminalId }.

Proposal

1. One server-side runScript. Web, mobile, and the feat(mcp): run saved project scripts #8714 tools call the same service method instead of opening a terminal and writing to it from the client. That brings mobile parity and removes the duplicated client logic.
2. Every run has a result. Reuse the setup runner's exit marker for all runs, giving running | succeeded | failed, the exit code, and the duration.
3. Runs appear in their thread. A run shows up in the thread that started it, with status, stop, restart, a link to its log (the run's terminal), and the linked port or preview. That works the same in the web and mobile thread views. The thread's sidebar row gets a running/failed indicator, which also covers [Bug]: The sidebar doesn't show a thread's running dev servers: the per-thread indicator exists only in the legacy sidebar and never counts servers the agent started #15238.
4. The thread hears when a run exits. Wake semantics are then the same across providers and don't depend on a provider's background shell staying alive.
5. Version skew. An ExecutionEnvironmentCapabilities flag lets older servers hide the feature.

Ownership follows the existing terminal rules. The thread that started a run owns it. The run stays open on settle like other terminals, and archive and delete clean it up.

Questions

• Agent defaults: once runs exist, should agents prefer t3_project_script_run over a provider background shell for a saved dev-server or build action? That would make the experience consistent, but it changes agent behavior.
• Cross-thread view: is a read-only "running in this project" view derived from the same data worth having, or is the per-thread indicator enough?

Out of scope

• Ad-hoc commands. Only saved actions become tracked runs, matching feat(mcp): run saved project scripts #8714's no-raw-command boundary.
• Surviving a server restart, autostart, and runs owned by a project rather than a thread.
• Processes detached with nohup/setsid ([Bug]: Settle leaves running a dev server the agent started with nohup … &, and nothing in T3 can find or stop it afterwards #15241).

Related

• PRs: feat(mcp): run saved project scripts #8714, feat(server): run a project action when a worktree thread settles #16290, fix(server): settle no longer leaves monitors and dev servers running #5774, fix(clients): a thread left running a dev server alerts as completed #14213, fix(clients): a dev server left running no longer says the thread is waiting #15114
• Issues: [Bug]: The sidebar doesn't show a thread's running dev servers: the per-thread indicator exists only in the legacy sidebar and never counts servers the agent started #15238, [Bug]: Settle leaves running a dev server the agent started with nohup … &, and nothing in T3 can find or stop it afterwards #15241
• Ideas: Project actions: running state, stop, and auto-stop when a thread settles #11254, Wake a thread when a command it started exits, even after its turn ends #16588, [Feature] Allow project actions to run without opening the terminal #8478, Proposal: expose thread-aware process launch and disposal hooks #13081

If this direction works for you, I'm happy to implement it on top of #8714.

[sergical]

+1. Concrete case from daily use: when an agent starts a dev server today, it's either a provider background shell (agent sees output, I only see "Running: …") or I start it in the terminal drawer (I see live logs, the agent can't read them). Agent-owned runs in a thread terminal (#8714) plus a visible result per run would let both of us see the same process, and stop it from either side.

[jamesondh]

A related bug: a background test run triggers a false "Thread completed"

I keep getting "Thread completed" notifications for threads that are still waiting on a test the agent started in the background. Here's the sequence:

1. The agent starts npm test as a background shell and ends its turn ("waiting on tests…").
2. The run completes and the thread reads as ready, so the Done notification fires.
3. The test exits, the agent is woken, a new run starts, and a second completion notification fires later.

The cause is backgroundWorkHoldsCompletion in packages/shared/src/orchestrationV2PendingBackgroundWork.ts. Subagents and monitors hold completion, but command deliberately doesn't. That was the fix for #14872, where dev servers kept threads in "Waiting" for hours. The rule uses the kind of work to guess whether the agent will resume, and that guess fails for commands. Every background command wakes the agent when it exits: Claude's SDK does this itself, and for Codex T3 sends the continuation. So nothing in the data separates "I'm waiting on this test" from "this dev server is yours now". Only the agent knows which it meant.

This proposal could fix that. A tracked run is either:

• a job (test, build): it holds the thread as waiting and wakes it with a result, or
• a service (dev server): it's handed off, doesn't hold completion, and shows as a running indicator on the row.

That only covers saved actions, though, so ad-hoc commands still need a fix. Two smaller changes would help in the meantime:

• Short grace period. When a run completes with commands still running, hold the completion notification for a few minutes. If a command exits and wakes the agent in that time, the next completion replaces the held one. Tests usually finish inside the window and dev servers don't, so [Bug]: Sidebar hides a finished thread's unseen completion while a background shell it left running is still alive #14872 stays fixed.
• Honest labels. Change the notification and the Done row to "Finished · 1 command still running" instead of a plain "Completed". Today only the mobile thread detail screen shows that a command is still running.

Separately, the status vocabulary is muddled. Run status waiting means the checkpoint is still being captured, and the sidebar shows it as Working. The sidebar's "Waiting" label means the thread is held by background work. And the old status pill (resolveThreadStatusPill) still exists alongside the newer sidebar status model. Merging them into one model with one meaning per word would make this state machine much easier to reason about.

[pioootrek]

+1, and the "false Thread completed" bug (is that really a bug?) is the symptom of the same root cause: the run belongs to the agent, so the app has to guess what the agent will do next.

What ended up working for me, outside T3 Code ->> the run belongs to a controller, not to the agent. The agent asks for a named preset (lint, typecheck, build, tests) for a specific worktree over MCP, the controller queues it (one at a time per project, so two threads cannot start two builds at once), runs it, and stores the result with the commit and the uncommitted diff it ran against. The agent polls or waits for a terminal state and the result is the same record I read from the dashboard or from my phone. Nothing in the thread's terminal, nothing to scroll back through, and a green result cannot be mistaken for a green result on different code, which was my actual problem. And yes, it's sharable across all coding apps / agents / etc.

Dev servers are a separate thing in that model, because they are not finite ( I'm don't want to spend tooo much on hw). A thread claims a project (or better claims dev server) before starting or switching the server, the claim expires, and the server keeps running after the thread settles by design. That answers the "hand-off at the end of a turn" case directly: the hand-off is explicit, visible, and not tied to the thread lifecycle.

Mine is here if the comparison helps the design: https://github.com/pioootrek/worktree-control (pre-1.0, Linux verified). It sits next to T3 Code (on my remote linux coding worker) rather than inside it, but the two pieces that mattered were "run has a result record" and "the result names the code it ran on", which this proposal already lists.

[seankoji]

Another case for this, from a Claude thread on desktop 0.0.46-nightly.20261013 (Linux).

The agent started a long verification job with Bash run_in_background ("Run bound gate checks for both PRs after the suite finishes"). It ran for over 10 minutes and spawned about 15 test worker processes. The composer strip showed the description and a Stop button, and nothing else did: not the terminal panel, not the Tests panel, not the sidebar. I had to ask the agent whether it was still alive, and it had to run pgrep to prove it.

What would have answered that without asking:

• the command line and how long it has been running
• the last few lines of its output (Claude already writes an output file per background task and returns the path in the tool result)
• the exit code when it finishes

The output tail is the part #15584 leaves out, and it matters most for long jobs that print progress. One catch: Python and many other tools buffer stdout when it goes to a file, so a live tail can sit unchanged while the job is working. Showing "last output 4 min ago" next to the tail would stop a quiet job reading as a hung one.

[jamesondh]

Another example from today, on 0.1.3-nightly.20261026.3717: a dev server left running held up a delegated task.

GPT (Codex) was overseeing implementation delegated to Claude through async delegate_task. The tool told GPT that completion would wake it automatically. Claude finished, posted its report with passing checks, and explicitly left a Vite dev server running for verification. The child thread showed as completed, but GPT wasn’t woken.

About seven minutes later, I noticed from my phone and told GPT that Claude looked finished. GPT read the handoff and continued with verification, independent review and pushing the branch.

When GPT subsequently stopped the dev server with SIGTERM, its “Delegated task … finished” notification arrived about 190 ms later. Stopping the server also woke Claude with a “Command … failed” notification, prompting another turn explaining that exit 143 was an intentional shutdown.

The source explains the delay: delegatedTaskProgress holds completion while anything remains in the child’s background roster, following #22709. Meanwhile, #24610 lets the thread itself finish with unmarked commands still running. The child can therefore read as completed while its parent waits for the dev server to exit.

This adds another example of the job/service distinction from my earlier comment: a child needs to hand back its result while leaving a service available for verification, without losing the protection against reporting completion before tests finish. From mobile, I had to recognize the stalled handoff and intervene.