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.