[FEATURE]: A roster view for backgrounded sessions (I built one, would you want it in core?) #39583

Feature hasn't been suggested before.

• I have verified this feature I'm about to request hasn't been suggested before.

Describe the enhancement you want to request

This has been asked before and keeps going stale instead of getting an answer: #27746, #24451, #17838, #12548. I'm not re-asking cold. I built it against the current server, so I can answer design questions with something real instead of a mockup, and CONTRIBUTING says UI features need a design review before implementation, so I'd rather ask than open a PR nobody wants.

What I built is https://github.com/costajohnt/fleetview. One screen listing every backgrounded opencode session across every project, grouped by state (working, needs input, completed). You type a task at the bottom to dispatch a new session, press enter on a row to attach into the real opencode TUI, ctrl+z to come back out. Close it and the sessions keep running. It's a deliberate port of Claude Code's agent view and the README says so up front.

The reason I think this belongs in core rather than staying a third party client: it's a thin client precisely because opencode is already client/server. REST for actions, one /event SSE stream per project for status, opencode attach for the handoff, /experimental/worktree for isolation. I did not have to reimplement any session logic. Everything the roster needs is already in the server, which reads to me like a missing view rather than a new subsystem.

Four things I ran into building it that are worth something to you either way:

1. Per-session worktrees are what make parallel dispatch actually usable. Three sessions dispatched into one repo without them means three agents editing one working copy. /experimental/worktree already does the right thing. Is it stable enough to depend on, and is it heading toward non-experimental?
2. The worktree delete path has no guard for a branch holding commits that exist nowhere else. I check client side before calling it, but that check really belongs in the server.
3. opencode serve has no auth by default and exposes a route that runs shell commands, so anything that can reach 127.0.0.1 as your user can execute code, including a browser page via DNS rebinding. OPENCODE_SERVER_PASSWORD fixes it and works well, it's just off by default. Happy to file that separately if you'd prefer it not ride along with a feature request.
4. "needs input" is the state that makes the view worth opening at all, and deriving it reliably from the event stream was the fiddliest part of the whole thing. A clearer signal there would help any client.

So, three questions, and no is a fine answer to the first one:

1. Do you want a roster view in core at all, or would you rather this stay a third party client?
2. If you do want it, where does it live? A new opencode agents command, something inside the existing TUI, or the web UI?
3. If you don't want to own the view, would you take the smaller pieces? Documenting the worktree endpoint, the unpushed-commit guard, and a clearer needs-input signal on /event would make every third party roster better, mine included.

Wire shapes are verified against 1.18.4 and I'll re-verify against 1.18.9.