V2 default background service makes session lifecycle implicit — orphaned runs, stranded permission prompts (design feedback) #52206

Summary

OpenCode v2 runs as a persistent background service by default (opencode serve --service), and the TUI is just one client attached to it. I understand this is a deliberate "service-first" architectural choice, but I want to raise some concrete UX consequences that made v2 feel like a regression for interactive use, and suggest mitigations.

Background

In v1, opencode was a single foreground process: closing the terminal or Ctrl+C stopped everything. The process lifecycle was explicit and matched the user's mental model — what you see running is all that's running.

In v2, exiting the TUI only disconnects one client. The service keeps running, and so do in-progress sessions.

Concrete problems

1. Orphaned sessions keep running (and keep spending tokens)

After I close the terminal, a session that was mid-run continues headless. By the time I reconnect — or if I never reconnect — it may have completed work I no longer need, producing results I didn't ask for. Worse, there is no obvious way to interrupt it from where I am: the "entry point" I closed was just a window onto the process, not the process itself.

2. Permission prompts can arrive when no client is attached

Permission requests are delivered to connected clients. If a request fires while I'm disconnected — e.g. right after I close the TUI, or before I open a new one — nobody is there to answer allow/deny. The request just sits there (or eventually times out). For an interactive agent this is a real gap: the agent is blocked on a question nobody can hear.

3. No explicit lifecycle management

Without pgrep, I can't tell whether the service is running. Nothing in the TUI exit flow says "the service and N sessions are still alive in the background". For users who manage their machines explicitly ("when I close it, it should be gone"), a daemon that quietly outlives its entry point is a problem in itself — independent of resource usage (which others have already reported, e.g. #42271).

What I'd like to see (any of these would help)

1. A prominent foreground mode. --standalone exists but is buried in --help. Consider making foreground the default when launched interactively from a TTY, with the background service as the explicit opt-in (opencode service start remains for those who want it). At minimum, print a notice on TUI exit: "background service still running with N active sessions".
2. Pause on last-client-disconnect (opt-in or opt-out). When the last client disconnects mid-run, pause the session instead of continuing headless, and surface it on next connect.
3. Graceful permission handling when headless. If a permission request fires with no client attached, pause the session and re-surface the prompt on next connect, rather than hanging until timeout.

Environment

• OpenCode v2.0.18 (Homebrew, macOS ARM64)

Related but distinct from: #51329 (Terminal.app quit blocked by leaked service process), #50633 (Windows service remains after app close), #45938 (macOS orphan cleanup) — those are about cleanup/resource bugs; this issue is about the lifecycle-by-default design for interactive sessions.