Tracked runs for project actions, so builds and dev servers have visible results on every client

[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.