service: idle background daemon holds ~700-800MB RSS

Summary

The serve --service background daemon stays resident 24/7 holding ~700-800 MB RSS with no active sessions and 0% CPU (97% of sample frames in kevent64 wait), which shows up as a permanent memory/energy footprint in Activity Monitor on a 16 GB MacBook Air.

Environment

• opencode version: 0.0.0-next-17403 (next channel, V2 beta)
• OS: macOS 26.6.1 (Darwin 25.6.0, arm64)
• Terminal: Apple_Terminal, TERM=xterm-256color
• Shell: /bin/zsh
• Install/channel: local binary in ~/.opencode/bin, channel next
• Active plugins: ~/.config/opencode/plugins.v2/memory.ts (opencode-memory)

Reproduction

1. Run opencode2 in a terminal (attaches to the serve --service daemon).
2. Close the TUI session; the daemon remains in the background.
3. Measure: ps -o pid,rss,pcpu,command -p <daemon-pid> and sample <daemon-pid>.

Observed:

• Daemon RSS: ~700-780 MB while idle, 0% CPU
• sample: main thread 1676/1729 frames in kevent64 (waiting), all worker threads in _pthread_cond_wait — fully idle but not releasing memory
• With an active TUI session (~600 MB) plus MCP children (~350 MB), total opencode2 footprint reached ~2 GB

Expected Behavior

An idle background daemon should hold a much smaller resident footprint (tens of MB), or exit when no sessions are active, or make residency configurable.

Actual Behavior

~700-800 MB RSS stays permanently resident even with no sessions open; macOS Activity Monitor reports it as a persistent energy/memory consumer and the memory is never reclaimed.

Additional Context

Workarounds: opencode2 service stop when not needed, or --standalone mode (private per-session server) to avoid a persistent daemon. Also observed: a leftover TUI session process remained in stopped state (T/SIGSTOP, ~240 MB RSS) after sessions were closed — likely job-control related, but it was not reaped either. Reproduction is consistent: the daemon holds this footprint every day.