[Bug]: OpenCode leaks orphaned /opencode serve processes that survive backend crash/restart #5241

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

1. Start T3 Code client + T3 Remote (i have the remote done via npx t3@nightly serve --host "$(tailscale ip -4)")
2. Start a new session with a OpenCode provider and send a message
3. Confirm the server is live and find its parent ps -eo pid,ppid,pgid,args | grep "[o]pencode serve"
4. Abruptly kill the backend - Simulating a crash / kill -9 / force-quit "C^
5. Observe the orphan - same command as step 2 -> the opencode serve is still alive but now with PPID = 1 (reparent ed to init)
6. Restart the T3 backend and wait for the session-reaper threshold -> ps -eo pid,ppid,pgid,etime,rss,args | awk '$2==1 && /[o]pencode serve/' -> the orphaned opencode serve would remain untouched as noting reclaims it only a manual kill or reboot of the machine would clear it.

Expected behavior

A provider server process that T3 spawns should have its lifetime strictly bounded by the T3 backend that owns it, regradless of how that backend terminates. Every one of these should tear the opencode serve down:

• Thread Stop button / Esc -> serve exits
• Graceful backend shutdown (normal quit, SIGTERM that completes teardown) -> all serves exit
• Abrupt backend death (crash, SIGKILL, OOM-kill, force-quit) -> all serves exit
• Backend restart -> no leftover opencode serve from prior runs; clean slate
• Prolonged inactivity -> idle serves reaped (the 30-min reaper)

Actual behavior

• Thread Stop / Esc -> serve exits
• Graceful quit /SIGTERM -> serves exit
• SIGKILL / crash / OOM / Force-quit -> serve survices - Orphaned to PID 1, never exits
• Backend restart -> prior serves still running, invisible to the new backend (still visible in the ui and actionable but not owned by the Backend Process) i think
• Inactivity reaper -> cannot reach orphans - it only closes session owned by a live backend

Damage — resources held by 28 orphaned opencode serve (measured live)

Top orphans by RSS:

Impact

Major degradation or frequent failure

Version or commit

main @ e60821f or t3: 0.0.32-nightly.20260802.980

Environment

Linux 7.0.0-27-generic x86_64, Node v24.18.0. Opecode 1.18.3

Logs or stack traces

No stack trace or log line exists for this: abrupt backend death precludes logging, and the orphaned opencode serve then runs silently. The evidence is the process table — 28 orphaned serves (PPID=1,PGID==PID, ages up to 10 days) holding ~9 GB RAM, 28 loopback ports, and 56 handles on a shared 13 GB opencode.db whose WAL can no longer checkpoint.

Screenshots, recordings, or supporting files

No response

Workaround

A potential option on how to fix this:

1. Record the spawn i.e small JSON file or something,
2. Reap on startup i.e for each record check if its pid is alive AND its PPID is 1 (i.e its been orphaned) -> kill it. if its pid is dead -> drop the entry. then rewrite the file with whatever is still legitimely alive.

but this depends on how often you "restart" T3 backend (i.e right now with lots of updates so would this be fine but a process which does not depend on the "restart" rate would be good later)