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
- Open a terminal (SSH or local)
- Run
opencode
- Use it for a while (interact with an agent, run tools, etc.)
- Close the terminal window or disconnect SSH without exiting opencode
- 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
- On
SIGHUP (terminal disconnect): opencode should clean up and exit within a reasonable timeout (e.g., 5-10 seconds)
- If graceful shutdown hangs (waiting on MCP servers, API calls, etc.): force exit after timeout
- 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.
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
Reproduction
opencodeRepeat 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:
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
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
SIGHUP(terminal disconnect): opencode should clean up and exit within a reasonable timeout (e.g., 5-10 seconds)Workaround
Manually kill orphaned processes:
Impact
On resource-constrained machines (ARM SBCs, small VMs) this is particularly painful — a few forgotten sessions can OOM the machine within a day.