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

[pt704]

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.

1-processes-page-overview.mp4

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.

2-agents-manage-processes-and-actions.mp4

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.