Services in the thread details card: see, open, and stop what a thread is running

[guillermolg00]

The problem

I keep my code on a Linux server and drive T3 Code from my laptop or phone over Tailscale. Agents start dev servers all the time: next dev, an API in watch mode, Expo Metro. From the client I can't easily answer simple questions:

• What is this thread running right now?
• Which port is it on, and what URL do I open from this device?
• Did it crash?
• How do I stop it when I'm done?

Today I ask the agent, or SSH in and run ss -ltnp. On a phone that is painful.

The idea

Add a small Services section to the thread details card, under Version Control. It lists what the thread is running, like Lineage lists agents.

• One row per service: a name, a status dot, and the port.
• Click a row to copy the URL that works from this device (for me, the tailnet URL). The port briefly changes to "Copied".
• Hover shows a card with who started it (agent or terminal), the status and uptime, every URL, and the command. Two actions appear: open ↗ and stop ■.
• Crashed services show "Exited" in red. The hover shows the last error line, and the action becomes restart.
• Names are written by AI. Instead of node or :3000, a small model names the service from its command and folder, for example "Vlue web" or "Kafka consumer". The hover says where the name came from. Renaming by hand always wins.

Scope

Small on purpose. It only shows what this thread started.

In	Out
Services started by this thread's agent or terminals	A global page for all processes (#17456 covers that)
Copy URL, open, stop, restart	Logs, CPU charts, editing commands
AI names plus manual rename	Run results for builds and tests (#16680 covers that)

What already exists

Most of the pieces are already in the repo:

• PortScanner finds listening ports and checks if they are web servers. It links a port to a thread only when a T3 terminal started it.
• resolveDiscoveredServerUrl already turns localhost:3000 into a URL that works from a remote client.
• On Linux, agentScope runs each thread's agent and terminals in their own systemd scope.

What's missing is linking ports to the thread when the agent started the server, which is the common case. On Linux the scope makes this reliable: read the listener's cgroup, map the unit to its thread, and you also get a safe way to stop it (systemctl --user stop <unit>) without killing by name. macOS and Windows could fall back to the process tree, or show nothing at first.

How it relates to other ideas

• Processes page: see and manage dev servers, agent shells and project actions in one place #17456 Processes page: a full page for everything running on the machine. This is the small, in-context version inside the thread. They can share the same server data.
• You can't tell if an agent's build, test, or dev server passed without asking it #16680 run results: about builds and tests passing or failing. This is about long-running servers you want to open.
• Prefer named dev-server URLs over raw localhost ports #14821 named URLs: that priority (ngrok → Tailscale Serve → Portless → localhost) would decide which URL "click to copy" uses.

Questions for maintainers

1. Is the thread details card the right place, or should this live somewhere else?
2. Is cgroup-based linking on Linux acceptable as a first step, with other platforms later?
3. Is AI naming welcome, or should names come from the command only?

I have a working UI prototype with mocked data (screenshot above). I won't open a PR unless the direction and scope are approved.

[juliusmarminge]

Note

Grok responding on behalf of Julius.

Thanks for the detailed write-up. This is the same need as #17456 (Processes page): see what an agent or terminal started, which port it's on, whether it's still alive, and stop or restart it, with each process linked back to its thread. A per-thread Services list in the details card is a view over that same server data, so I'm closing this as a duplicate to keep the discussion in one place.

The parts that are new here are worth adding as a comment on #17456: showing the thread's services in the details card, linking agent-started listeners to threads through the Linux agentScope cgroup (and stopping via the unit), click-to-copy of the remote-reachable URL (with #14821 picking which URL), and AI-generated names. Please hold the prototype PR until the direction there is settled.