No way to see which routine sessions are still alive and holding resources

Summary

A routine run whose session has exited and one whose session is still resident on a remote-control bridge look identical in the UI. Both display as succeeded. Nothing indicates a process is still alive.

Fourteen sessions accumulated on my bridge over ten days, one per routine firing, none exiting after their run completed (#93549): ~1.9 GB RSS combined, each ticking 0.5–2% CPU while idle. The only two signals I found were the claude remote-control terminal's attached-session count and ps on the host, neither of which is intuitively the surface to monitor.

Leaked sessions hold the bridge's concurrent-session capacity. When it fills, the next firing cannot spawn and a scheduled job silently stops running, with no warning surface in front of it and no failed run to show for it afterwards. Being unable to find a completed routine is an inconvenience; being unable to tell that something is still consuming resources means the problem stays invisible until it breaks something.

Request

1. Track session liveness server-side, so a session whose process has exited stops reporting active.
2. Make a live session visibly distinct from a finished one wherever runs or sessions are listed.
3. Surface a per-environment count of live sessions against capacity. That number predicts the outage, and the bridge terminal already prints it locally.

There is no liveness signal in the API either

GET /v1/code/sessions?trigger_id=… returns status and worker_status. Neither tracks whether the process is alive:

| Session state | status | worker_status | process |
|---|---|---|---|
| Mid-turn | active | running | alive |
| Run completed, process leaked | active | idle | alive |
| SIGTERMed hours earlier | active | idle | dead |
| Archived | archived | idle | dead |

worker_status only separates "running a turn" from "not"; status only separates archived from not. A leaked session and one killed hours ago are indistinguishable.

Ten sessions I SIGTERMed at 01:00 still reported active at 02:45, processes long gone. So the server's own record of which sessions are alive is wrong, and no client could render the truth from it today.

Contributing factor

Fired one-shot routines are hidden from the routines list by default, and the filter menu (All / Active / Paused / Auto-Disabled / On Hold) does not reach them: a fired one-shot is enabled: false with ended_reason: "run_once_fired", yet does not appear under "Auto-Disabled", and "All" excludes it. The control that reveals it is "include completed", under sort. So a leaked one-shot session is hidden twice over.

Environment

Claude Code 2.1.247, Claude Desktop app, macOS (Apple Silicon), cloud routines targeting a kind: bridge environment.

Related

• #93549: routine sessions are never sent end_session on completion, the leak this defect makes invisible
• #72308, #68626, #73631: session and process leaks on other spawners
• #74682: auto-archive routine sessions after completion
• #86115: paused scheduled tasks disappearing from the Routines list