Repository navigation
[FEATURE]:Official - OpenCode VS Code extension #11176
Description
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
Summary
I’d like OpenCode to be available as an official Visual Studio Code extension, so it can run as a native panel/side view within VS Code instead of only as a standalone terminal UI.
Problem
Right now, the typical way to use OpenCode is through a terminal. This works, but it has a few practical limitations for developers who live inside VS Code:
- Switching back and forth between the terminal and the editor breaks flow.
- The TUI doesn’t behave like a first‑class VS Code panel (e.g. resizing, layout persistence, focus, keyboard shortcuts).
- It’s harder to integrate OpenCode workflows with other VS Code features (source control, problems view, outline, etc).
For those of us using OpenCode as a central coding agent, having it only in the terminal makes the experience feel more like a separate tool than a tightly integrated part of the IDE.
Proposal
Create an official Opensource OpenCode VS Code extension that:
- Renders OpenCode in a dedicated view/panel (e.g. a sidebar or main panel) instead of just a terminal.
- Uses VS Code’s Webview / custom view / panel APIs (or similar) so:
- The OpenCode interface can be docked, resized, and positioned like other panels.
- Layout is remembered between sessions.
- Focus, keybindings, and navigation feel native to VS Code.
Possible features for the extension
- Integrated agent panel: A persistent OpenCode panel where the agent UI lives, rather than a transient terminal.
- Project‑aware context: Automatically picks up the current workspace, repo, and open files, using VS Code APIs instead of shell heuristics.
- Commands & keybindings:
- “Open OpenCode panel” command.
- Quick commands to send the current file/selection to OpenCode.
- Customizable hotkeys for common agent actions.
- Status bar integration: Simple status indicator (e.g. agent running, thinking, idle, error).
- Configuration UI: VS Code settings page for OpenCode config, keys, backends, etc., instead of editing config only via files/CLI.
Benefits
- Better UX inside VS Code: OpenCode feels like a first‑class citizen, similar to other popular AI/code tools that ship as VS Code extensions.
- Less context switching: Developers can keep OpenCode visible alongside editor, terminal, and source control.
- More discoverable and approachable: Installing from the VS Code marketplace greatly lowers the barrier to trying OpenCode for new users.
- Easier integration with other tools: Extension can hook into VS Code’s APIs to provide richer workflows (e.g. running specific tasks, opening files suggested by the agent, etc.).
Additional Context
My main use case is running OpenCode as a primary coding agent while staying entirely inside VS Code. Having an official extension that opens properly in a VS Code pane (instead of just a terminal window) would make OpenCode much easier to adopt and use as a daily driver for development.
Activity
github-actions commentedon Jan 29, 2026
This issue might be a duplicate of existing issues. Please check:
Additionally, related feature requests that address IDE integration challenges:
Feel free to ignore if none of these address your specific case.
altendky commentedon Jan 30, 2026
https://marketplace.visualstudio.com/items?itemName=sst-dev.opencode
https://marketplace.visualstudio.com/items?itemName=sst-dev.opencode-v2
i think these are official extensions. though yes, plenty of room for improvement. i started #7275 but haven't gotten any traction here yet with even just the bug fixes i made along the way. they are busy here... 1.2k PRs and all.
Pl8tinium commentedon Jan 30, 2026
this is a great proposal
cboettig commentedon Mar 3, 2026
Would be great to see progress on these, neither of the current versions are really functional in vscode.
https://marketplace.visualstudio.com/items?itemName=sst-dev.opencode is essentially just opening a window with opencode running in the terminal -- no actual GUI interface for selecting models etc. Note that essential shortcuts like
ctl+pare overridden by vscode hotkeys, so not functional here or in the terminal.https://marketplace.visualstudio.com/items?itemName=sst-dev.opencode-v2 looks like more promising sidebar integration, consistent with how most other major providers (cline, roo, continue, claude, codex, copilot etc) have implemented their vscode / vsx extensions. However the opencode one doesn't seem to be functional. (error: "There is no data provider registered that can provide view data." even while the non-beta extension is connected fine)
altendky commentedon Mar 3, 2026
i've tried to get just small bug fix PRs through but i think the team has been too busy for even that. otherwise i might have done more on my efforts to improve this integration.
baob commentedon Mar 12, 2026
There's a specific issue for this: #10119
WustLCQ commentedon Mar 16, 2026
This is a great issue. Compared to TUI, more members of our team still prefer using a GUI plugin in VSCode.
afaraha8403 commentedon Mar 21, 2026
Coming from Kilocode, Cline and Roo Code to opencode this is the only thing that is missing that would seal the deal and allow me to STOP using these other tools.
Yes granted that that you can use the TUI or the GUI app, but this proposal; at least to me seems like a no brainer!
rosmur commentedon Mar 24, 2026
Im in the same position as @afaraha8403 .
It looks like there is a VS code extension now: https://marketplace.visualstudio.com/items?itemName=sst-dev.opencode
But without screenshots, its hard to tell if this does what we are asking for
cboettig commentedon Mar 25, 2026
@rosmur there have been two vscode extensions for a while now as I link above.
And no, neither does what we are asking for, they are basically identical to just running opencode in the vscode integrated terminal. Even that experience is far worse than it sounds, for instance -- as we all know, the command list in opencode is
ctrl + p, which vscode already assigns to it's own command pallet, making it inaccessible unless the user disables this standard hotkey in vscode. This same issue impacts both of the vscode plugins. Without easily being able to even open the command list it hard to imagine anyone actually uses opencode inside vscode. It does work so nicely in a regular terminal of course.Here's a screenshot of opencode just running in terminal (but vscode 'extensions' seem to be functionally identical to this). Contrast that to the kind of integration we see on the right-hand menu for claude (or roo code, or copilot, or any first-class extension, but claude is a good example of another client that is obviously cli-first design, but nevertheless implements a meaningfully useful GUI here -- note the
/command has been turned into a clickable button, the open file is displayed as the context, and the interface is rendered in rich-text).cpkt9762 commentedon Apr 9, 2026
I’ve developed a VS Code Web extension using Opus 4.6. It is currently working correctly; if anyone is interested, feel free to fork, modify, and improve it.
https://github.com/cpkt9762/opencode-web-for-vscode
cbarkinozer commentedon Apr 13, 2026
A VS Code GUI could improve popularity and the ease of use.
15 remaining items
vuon9 commentedon Jul 27, 2026
VSCode recently integrated Agent Host Protocol (AHP).
I could see it's already working well with Claude CLI.
I'm not sure if having an extension now is more helpful than making the OpenCode CLI works for GitHub Copilot Chat for a seamless experience?
mmospanenko commentedon Jul 27, 2026
they even mentioned ACP in this post...
druellan commentedon Aug 5, 2026
I think it makes more sense, as a development effort, to support and maintain a protocol, especially because we already have extensions like Openchamber that provide a very solid chat integration.
mmospanenko commentedon Aug 6, 2026
100% agree with @druellan and @vuon9.
OpenChamber is already handling the UI/chat integration layer exceptionally well and pacing fast.
Rather than duplicating effort to build and maintain an official extension, OpenCode's development bandwidth is much better spent on implementing low-level protocol standards (ACP / AHP) and engine features. Let the ecosystem handle the GUI surface!
GF-Huang commentedon Sep 7, 2026
We don't need another IDE/Editor.
hussain commentedon Oct 7, 2026
Along the lines of @druellan and @mmospanenko: OpenCode already speaks ACP (
opencode acp), so any ACP client can give it a VS Code panel without a separate extension from the OpenCode team.I maintain ACP Patchbay (Apache 2.0, also on Open VSX), a VS Code ACP client. OpenCode installs from the ACP registry in two clicks and runs in a side panel, keeping OpenCode's model picker, slash commands and MCP config:
Docs PR to list it on the ACP page: #53795
GF-Huang commentedon Oct 8, 2026
@hussain Good extension, but it seems not allow me to use local
opencode.exe(v2), it force me to download the v1.hussain commentedon Oct 8, 2026
This is because v2 is not in ACP Registry yet (not managed by us), but you can add any agent manually using
Add customand command isC:\...\opencode.exe acpwhich is the binary location.Be sure to run
opencode auth loginin terminal firstsince opencode v2 doesn't support ACP authentication yet, unless you update the API key in edit as in screen last step.EDIT: @GF-Huang Correction on auth: v2 (2.0.25) does offer an ACP login. Once it asks for auth, Patchbay shows a Log in button that runs
opencode auth loginin a VS Code terminal. It runs whicheveropencodeis first on your PATH, so make sure that's the v2 binary, or just run the login in your terminal first as above. tracked in solutionsunity/acp-patchbay#93deepakajay0477 commentedon Oct 16, 2026
VSCodium user here (Open VSX only — the Microsoft Marketplace isn't available). Putting in a concrete, scoped request building on everything above and on the fixes tracked in #52455 / #50530.
Where things stand (verified today)
sst-dev/opencodev1.0.0 is live on both the VS Code Marketplace and Open VSX, and per [FEATURE]: OpenCode extension update on Open VSX registry #52455 it now launches the V2 CLI correctly.sdks/vscodeis already at version 2.0.31 while the published artifact is 1.0.0 — the published build and the repo have drifted. The publisher is also stillsst-dev, notanomalyco, which makes "is this official?" harder than it should be.ponces/opencode2.0.31, OpenChamber, ACP Patchbay, opencui, varro, …). Genuinely good work by the ecosystem, but it fragments trust and version tracking.The ask (editor parity with the other big AI providers)
ChatGPT, Claude and Gemini all ship first-party VS Code/VSCodium extensions. Please give OpenCode the same:
anomalycopublisher on both the VS Code Marketplace and Open VSX, with releases tracking the CLI. VSCodium support is a distinct audience, not an afterthought — Open VSX is the only registry VSCodium can install from by default.opencode acpas the official integration path: keep it fully supported for v2 (sessions, model/agent config, permissions, diffs, auth) and list recommended ACP clients in the docs so users have a sanctioned answer instead of guessing.A thin terminal launcher is fine as a start, but since the v2 server + ACP already expose sessions, permissions, diffs and usage, an official panel client looks achievable without re-implementing the agent engine — which also keeps the CLI-level speed and control the terminal is loved for.
Happy to test on VSCodium (Windows, Flutter/Android dev environment) and file focused follow-up issues. This is the one gap keeping OpenCode from being a full drop-in for the many developers who can't or won't use the Microsoft marketplace.
hussain commentedon Oct 21, 2026
@GF-Huang OpenCode V2 is now in the ACP registry (
opencode-v2, agentclientprotocol/registry#657). In ACP Patchbay it installs from the agent list in one click and works right away; I tested it today. The same entry serves every client that installs from the ACP registry.GF-Huang commentedon Oct 22, 2026
@hussain Why I can't use the local one?
hussain commentedon Oct 22, 2026
@GF-Huang Thanks for the screenshots, that's a bug on our side: editing the command of an agent added from the registry doesn't take effect, because the card keeps its registry link and still downloads the registry build. Tracked in solutionsunity/acp-patchbay#121. Until it's fixed, add your local
opencode.exe acpwith Add agent → Custom instead of editing the registry card.opencodejr commentedon Oct 29, 2026
Thanks for the detailed request! You're asking for the official VS Code extension to show OpenCode in a native panel or sidebar instead of running the TUI in a terminal. You also suggest sending the current file or selection, a status bar indicator, native keybindings and a settings UI.
There is already an official extension (source in
sdks/vscode), but at the moment it only opens OpenCode in the integrated terminal. It has:Ctrl/Cmd+Esc(andCtrl/Cmd+Shift+Escfor a new tab) to open OpenCodeCtrl/Cmd+Alt+Kto insert the current file path as an@-mentionThe native webview panel you describe would be new work. Maintainers will consider it.
coofercat commentedon Nov 7, 2026
I've been using the opencode VSCode extension for a while - it's pretty great. As a Cursor-at-work user, it's pretty familiar :-)
I'd like to ask that in the current iteration, we make the-thing-that-gets-run into a configurable option. At the moment it's to start an opencode server and then run
opencode, but I'd like to change it to skip starting the server and runopencode --server 127.0.0.1:49374instead (assume I've already got the server running, and listening on localhost) - that way, my Opencode agent can run in a container (possibly slightly more secure?).Going forwards, with further VSCode integration, keeping things in containers may become harder. I'd urge you keep it in mind though, as having an agent with (potentially) full access to my entire laptop doesn't really appeal, and even Cursor and the like keep theirs more locked down than that.
dzid26 commentedon Nov 8, 2026
Why does it need to download at all? Ideally it would just check if a opencode is on the path first.
Also, nit, my installation didn't have
opencode.exeone the PATH, justopencode.So currently the flow is Reject download -> Edit crashed connector -> use
opencode acpas the command.