Feature 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:
- 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?
- 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.
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.- "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:
- Do you want a roster view in core at all, or would you rather this stay a third party client?
- If you do want it, where does it live? A new
opencode agents command, something inside the existing TUI, or the web UI?
- 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.
Feature 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 attachfor 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:
opencode servehas 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.So, three questions, and no is a fine answer to the first one:
opencode agentscommand, something inside the existing TUI, or the web UI?Wire shapes are verified against 1.18.4 and I'll re-verify against 1.18.9.