opencode -c/-i TUI sessions hang permanently: zombie git child under project-copy-refresh snapshot step

Summary

Interactive opencode -c / -i TUI sessions occasionally hang permanently (0% CPU, no output, no error, no timeout) due to a zombie child process left behind by the startup "project copy refresh" snapshot step.

Root cause

On session start, opencode spawns a git subprocess to snapshot the project (for the undo/checkpoint feature). Under load, that subprocess sometimes exits but opencode's runtime never reaps it / never resumes waiting on it — leaving a zombie [git] <defunct> child and the parent opencode process permanently parked.

Evidence

Caught live in production use:

• PID with a session frozen 90+ minutes, two [git] <defunct> zombie children, all threads parked in futex_do_wait/ep_poll (0% CPU, confirmed via /proc/<pid>/task/*/stack).
• A second, older session (11 days old) also carrying a zombie [bash] <defunct> child under the same pattern.
• Verified the issue is client-side and not related to any model/gateway backend — an active local model endpoint responded normally (sub-3ms) while the opencode session was hung.

Contributing factor

~/.local/share/opencode/opencode.db grows unbounded — in our case it reached 4GB, with an internal event table (full replay log of every message/part update, seemingly for live-client resubscription) accounting for ~3GB of that across 565k rows, many belonging to sessions untouched for weeks/months. There's no CLI-exposed prune/gc for this (checked opencode debug snapshot --help, no relevant subcommand) and no flag on opencode run/session start to skip the snapshot/project-copy step. A larger snapshot/db footprint appears to widen the window for the zombie-reap race on session start.

Impact

• opencode run (headless, one-shot) dispatch calls are comparatively low-risk since external supervisors can apply their own timeout/kill.
• Unattended interactive -c/-i TUI sessions have no internal watchdog — a hit just sits indefinitely consuming a process/memory slot until a human notices and manually SIGTERMs it (which does cleanly reap it, for what it's worth — SIGTERM is sufficient, no SIGKILL needed).

Ask

• Reap/handle the git subprocess used for project-copy-refresh so it can't leave the parent permanently blocked (e.g. explicit exit-code + zombie reaping, or a bounded timeout on that step).
• Consider exposing a CLI flag to skip the snapshot step entirely for headless/CI-style invocations where undo/checkpoint isn't needed.
• Consider auto-pruning the event table (or exposing a opencode debug db prune-style command) so opencode.db doesn't grow unbounded.

Happy to provide more diagnostics (stack traces, timing) if useful.