Opencode processes survive terminal disconnect, become orphans, and leak memory

[ErcinDedeoglu]

Summary

When a terminal session is closed or an SSH connection drops without explicitly exiting opencode (Ctrl+C / exit), the opencode process is not terminated. It becomes an orphan (reparented to PID 1), continues to hold memory indefinitely, and leaks memory over time. On long-running dev machines, this leads to severe memory exhaustion.

Environment

• opencode version: 1.1.53
• Binary: Bun 1.2 compiled, ELF aarch64
• OS: Ubuntu 22.04.5 LTS (ARM64, Orange Pi)
• RAM: 32 GB

Reproduction

1. Open a terminal (SSH or local)
2. Run opencode
3. Use it for a while (interact with an agent, run tools, etc.)
4. Close the terminal window or disconnect SSH without exiting opencode
5. Observe: the opencode process continues running, detached from any TTY

Repeat a few times and watch memory disappear.

Observed Behavior

After a day and a half of normal usage (opening/closing sessions), 6 orphaned opencode processes accumulated:

PID	Age	RSS	TTY	PPID	State
140728	1d 17h	504 MB	? (none)	1 (init)	Sleeping
700891	1d 12h	11.2 GB	? (none)	1 (init)	Sleeping
254506	1d 16h	499 MB	? (none)	1 (init)	Sleeping
715951	1d 12h	2.5 GB	? (none)	1 (init)	Sleeping
1388538	21h	4.1 GB	? (none)	1 (init)	Sleeping
1703444	3 min	467 MB	? (none)	1 (init)	Sleeping

Total orphaned memory: ~19 GB out of 32 GB, making the machine nearly unusable.

Only 2 processes were actually attached to terminals and doing work.

Signal Analysis

SigIgn: 0000000001000000  (only signal 25 ignored)
SigCgt: 0000000128005cef  (SIGHUP is CAUGHT, not ignored)

SIGHUP (signal 1) is registered as caught, which means the process receives it on terminal disconnect — but it does not exit. The handler appears to swallow the signal without performing a clean shutdown.

Memory Leak

The oldest process (36h) grew to 11.2 GB RSS with 210 open file descriptors, while younger processes of similar age sat at ~500 MB. This suggests a memory leak in long-running sessions, likely from accumulated conversation context, MCP tool results, or unreleased buffers.

Expected Behavior

1. On SIGHUP (terminal disconnect): opencode should clean up and exit within a reasonable timeout (e.g., 5-10 seconds)
2. If graceful shutdown hangs (waiting on MCP servers, API calls, etc.): force exit after timeout
3. Long-running sessions should not grow unboundedly in memory — there should be some form of context/buffer pruning or ceiling

Workaround

Manually kill orphaned processes:

# Find orphaned opencode processes (PPID=1, no TTY)
ps -eo pid,ppid,tty,rss,comm | grep opencode | awk '$2 == 1 && $3 == "?" {print $1}' | xargs kill

Impact

On resource-constrained machines (ARM SBCs, small VMs) this is particularly painful — a few forgotten sessions can OOM the machine within a day.

[github-actions]

---

This issue appears to be a duplicate of existing reports about orphaned processes when terminals close. Please check these related issues:

• [BUG] Opencode process survives terminal close — missing SIGHUP handler causes orphaned process accumulation #12767: [BUG] Opencode process survives terminal close — missing SIGHUP handler causes orphaned process accumulation
• Memory Leak: Orphaned processes when terminal closes without explicit exit #10563: Memory Leak: Orphaned processes when terminal closes without explicit exit
• [BUG]: opencode attach processes not terminated when tmux pane is killed (zombie process accumulation) #11225: [BUG]: opencode attach processes not terminated when tmux pane is killed (zombie process accumulation)

All three issues describe the same root cause: missing SIGHUP signal handling leading to orphaned processes. #12767 already has an assignee. Please consolidate efforts on one of these existing issues to avoid duplicate work.