LSP processes remain as orphaned zombie processes after opencode exits, causing severe memory leaks

[jqlong17]

Summary

After closing opencode, multiple LSP server processes remain running in the background indefinitely, consuming significant system memory. This appears to be a systematic issue with process lifecycle management rather than an isolated bug.

Environment

• OpenCode version: Latest (built from source)
• OS: macOS (darwin/arm64)
• Node/Bun: Bun runtime
• Installation: npm install -g opencode-ai

Current Behavior

When opencode is launched and then closed, LSP server processes spawned for various projects remain alive as orphaned processes:

# After running opencode a few times across different projects
$ ps aux | grep opencode | grep -v grep | wc -l
20

# Memory consumption per process
$ ps aux | grep opencode.*-c | awk '{sum += $6} END {print sum/1024 " MB"}'
~1.2 GB

Root Cause Analysis (from Source Code Review)

1. Missing Process Signal Handlers

In packages/opencode/src/index.ts, only SIGHUP is handled:

process.on("SIGHUP", () => process.exit())

Missing: SIGTERM, SIGINT handlers for graceful shutdown.

2. Forced Exit Without Cleanup Time

packages/opencode/src/index.ts:215:

finally {
  // Some subprocesses don't react properly to SIGTERM...
  process.exit()  // Immediately kills process, no cleanup time for LSP
}

This forces immediate exit without allowing Instance.dispose() or State.dispose() to complete.

3. Instance Cache Never Expires

packages/opencode/src/project/instance.ts:15:

const cache = new Map<string, Promise<Context>>()  // Permanent cache, no TTL

Instances (and their LSP clients) are never cleaned up automatically.

4. LSP Processes Not Properly Tracked

packages/opencode/src/lsp/server.ts uses spawn() without process group management:

• No detached: true with process group tracking
• Parent death doesn't trigger automatic child cleanup
• Each new project creates new LSP servers that outlive the parent

5. State Disposal Timing Issues

packages/opencode/src/project/state.ts:39-46 warns about disposal taking too long (10s timeout), but the forced process.exit() in index.ts prevents disposal from completing at all.

Expected Behavior

1. When opencode exits (normally or via signal), all child LSP processes should be terminated
2. LSP servers should have idle timeout to auto-cleanup
3. Orphaned processes from previous runs should be detected and cleaned up

Steps to Reproduce

1. Open a project with opencode: opencode
2. Work for a while (LSP servers will spawn)
3. Close opencode (Ctrl+C or normal exit)
4. Check for lingering processes: ps aux | grep opencode.*-c
5. Repeat with different projects - processes accumulate

Proposed Solutions

Short-term (User Workaround)

Add to shell configuration:

# Kill orphaned opencode LSP processes on terminal exit
trap 'pkill -f "opencode.*-c"' EXIT

Long-term (Code Fixes)

1. Add signal handlers in index.ts:

   process.on("SIGTERM", gracefulShutdown)
   process.on("SIGINT", gracefulShutdown)
   
   async function gracefulShutdown() {
     await Instance.disposeAll()
     process.exit(0)
   }

2. Remove forced exit in index.ts finally block, or add delay:

   finally {
     // Give time for cleanup before forcing exit
     await new Promise(r => setTimeout(r, 2000))
     process.exit()
   }

3. Add LSP idle timeout in lsp/index.ts:

   // Auto-shutdown LSP servers after idle period
   setTimeout(() => {
     if (noRecentActivity) client.shutdown()
   }, IDLE_TIMEOUT)

4. Process group management in lsp/server.ts:

   spawn(command, args, {
     detached: true,
     // Track PIDs for cleanup
   })

Impact

• Memory: Each LSP process consumes 50-100MB, easily accumulating to 1-2GB+
• System resources: Zombie processes consume file descriptors and CPU cycles
• User experience: System slowdown, need for manual cleanup

Related Code References

• packages/opencode/src/index.ts:52, 215
• packages/opencode/src/project/instance.ts:15, 103-105
• packages/opencode/src/project/state.ts:31-69
• packages/opencode/src/lsp/server.ts (all spawn calls)
• packages/opencode/src/lsp/client.ts:238-244 (shutdown method exists but not called)
• packages/opencode/src/lsp/index.ts:141-144 (dispose handler registered but not triggered)

---

Severity: High - affects all users with multi-project workflows
Type: Bug / Memory Leak

[github-actions]

This issue might be a duplicate of existing issues. Please check:

• LSP process leak: rust-analyzer spawned repeatedly without shutdown, causes OOM #17287: LSP process leak with rust-analyzer spawned repeatedly without shutdown (very similar symptoms)
• JDTLS (Java Language Server) processes are never terminated after subagent sessions end, causing massive memory leak #15037: JDTLS processes never terminated after subagent sessions end, causing memory leak (same LSP lifecycle issue)
• [BUG] Opencode process survives terminal close — missing SIGHUP handler causes orphaned process accumulation #12767: Opencode process survives terminal close — missing SIGHUP handler causes orphaned process accumulation (nearly identical root cause analysis around missing signal handlers)
• Opencode processes survive terminal disconnect, become orphans, and leak memory #12913: Opencode processes survive terminal disconnect, become orphans, and leak memory (same orphaned process / memory leak pattern)
• Missing SIGHUP handler causes orphaned processes to leak ~4.7 GB each after terminal death #14504: Missing SIGHUP handler causes orphaned processes to leak ~4.7 GB each after terminal death (directly overlapping root cause)
• Memory Leak: Orphaned processes when terminal closes without explicit exit #10563: Memory Leak: Orphaned processes when terminal closes without explicit exit (same class of issue)
• ElixirLS: LSP client spawns new process per request, causing timeout and process leak #12596: ElixirLS LSP client spawns new process per request, causing timeout and process leak (same LSP cleanup failure)

If your issue is specifically about LSP child processes outliving the parent opencode process (rather than the opencode process itself becoming orphaned), #17287 and #15037 are the closest matches. If it is about the opencode process itself not exiting on terminal close, #12767, #12913, and #14504 cover that. Please review these before continuing, and consider whether your report adds new information not already captured.

[jqlong17]

Thanks for the duplicate sweep — I reviewed the linked issues.

How this relates: My report focuses on LSP server child processes that keep running after the opencode process exits (multi-project use on macOS/arm64 with Bun), with ~1.2 GB residual footprint from lingering opencode … -c style processes. That aligns most closely with #17287 and #15037 (LSP lifecycle / shutdown), rather than only the "main opencode survives terminal close" threads (#12767, #12913, #14504).

What I hoped to add beyond older reports: concrete pointers in current code (index.ts signal/exit path, instance.ts cache, state.ts disposal timeout vs process.exit(), lsp/server.ts spawn behavior) and a minimal repro + ps checks, so maintainers can fold it into one fix path if useful.

I'm tracking #20006 (shutdown / orphaned process cleanup) — happy for this issue to be closed as duplicate of #17287 (or another canonical issue the team prefers) once that's merged or superseded, as long as the LSP-child cleanup case stays covered there.

[thdxr]

Closing in favor of #20695 where we're collecting all memory-related problems. Please follow that issue for updates.