Processes page: see and manage dev servers, agent shells and project actions in one place #17456

The problem

When I run several agents across a few projects, I lose track of what is running. There is a vite in a worktree an agent started an hour ago, a next dev in a T3 terminal, an API server in iTerm, and something holding port 3000. Finding and stopping the right one means lsof -i, ps and guessing which checkout it belongs to. Agents have the same problem. They start a second dev server because they can't see that one is already running, or they can't stop the one they started earlier.

Others have run into pieces of this: agent-started servers that survive settle and can't be found or stopped from T3 Code (#15241), running dev servers not showing in the sidebar (#15238), and requests for visible, stoppable project-action runs (#16680, #11254).

What I tried

I built a proof of concept in my fork: a Processes page next to Pull Requests and Usage, plus MCP tools so agents can do the same things.

Left column: what's running. It shows long-running commands in T3 terminals, project actions, background shells agents started, and, collapsed under External, processes started elsewhere that run in a project folder or listen on a port. Each card shows:

• the project, branch and ports;
• uptime and who started it (you, an agent, or something outside T3 Code);
• a link to the thread that started it;
• what it is, recognized from the process tree: Vite, Next.js, a Node or Python server, PostgreSQL, Claude Code, Codex, and so on.

Selecting a card shows its live output, CPU and memory. Stop sends Ctrl-C first, and T3 Code asks before stopping anything it didn't start. That also covers the case in #15241: a server an agent started with nohup still shows up here and can be stopped.

Right column: what you can run. Each project's saved actions, plus commands discovered in t3.json, package.json scripts, a Makefile or a Procfile. You can run a command, run a second instance, or save a discovered command as a project action. Discovered commands are only offered and never saved automatically, which keeps the idea from #913 opt-in.

A tour with on-screen captions: run a saved action and watch its output, restart and stop from a card, save a discovered command, and see processes started outside T3 Code.

Agents get the same abilities through seven MCP tools:

• t3_process_list
• t3_process_stop / t3_process_restart
• t3_project_actions_list / t3_project_action_run
• t3_project_action_save / t3_project_action_delete (full-access threads only)

Processes an agent starts show up on the page with a link back to its thread. Running saved scripts from MCP overlaps with #8714. If that lands, t3_project_action_run could sit on top of it, and what this adds is the process list, stop and restart for anything running, and discovered commands.

Three short requests to an agent (GPT-6.1-Sol): start a command from the Procfile and restart a server, save a new action and delete an old one, stop a server. Each change shows up live on the Processes page, linked back to the thread. Waiting time is cut, nothing is sped up.

How it fits

• Performance: nothing runs unless something is watching. While the page is open, or an agent calls the list tool, the server takes one ps + lsof snapshot every 3 s and shares it between subscribers. Unlike the always-on resource sampling in t3-resource-monitor samples every process on the machine every 5 s with no live subscriber and cannot be turned off #11222, it stops as soon as nobody is subscribed. The client receives one small list; output streams only for the selected process.
• Remote: everything goes through the existing WebSocket RPC and auth scopes. Listing needs terminal read; stop, restart and run need terminal operate. Port links open only when the client and server are on the same machine.
• Surfaces: web and desktop. I haven't built a mobile screen, though the RPC and client-runtime state are shared, so one could be added; that would also cover the mobile side of You can't tell if an agent's build, test, or dev server passed without asking it #16680 and Open a thread's linked dev servers from mobile #14822. Windows lists T3 terminals only, with no machine-wide scan.

Things I'm unsure about

• Whether External (processes T3 Code didn't start) belongs in T3 Code at all, or only what T3 Code started.
• Recognition is a fixed list of known agents, frameworks and databases.
• Who-started-it is kept in memory, so it's lost after a server restart. The thread-aware process ownership proposed in Proposal: expose thread-aware process launch and disposal hooks #13081 would be a sturdier source.
• Whether actions should stop automatically when their thread settles (Project actions: running state, stop, and auto-stop when a thread settles #11254). The page makes that visible, but I left it out.
• How this should look with Docker sandboxes (feat: threads can run in Docker sandboxes with their own ports and services #15350), where each thread's services run in their own container.

Code

• Branch: https://github.com/pt704/t3code-pt/tree/feature/processes-page (rebased on current main)
• Diff: pt704/t3code-pt@main...feature/processes-page

It's about 4.4k lines across contracts, a ProcessTracker service, an MCP toolkit, the web page and tests. It's a proof of concept to show the idea; I'm not asking for a review or a merge. If the direction is interesting, I'm happy to reshape it, split it into small pieces, or hand it over. If it doesn't fit your plans, that's completely fine; it'll keep running in my fork.

The dedicated save and delete tools exist because t3_project_update's scripts field no longer changes a project's actions since project settings moved into projectSettingsOverrides. That's already tracked in #14991, with a fix in #15012.