You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Good idea! We could potentially provide a Docker image for the web UI part that runs standalone (without VS Code). Would that cover your use case?
There is already that . What we could aim for is a combination of the two so opencode is sandboxed into the project scope directory via the container while using VSCode as its GUI
Thanks for the clarification — that's a much sharper framing than my
"standalone web Docker" suggestion, and you're right.
For context on what we're already exploring on the "VS Code as GUI +
decoupled opencode backend" axis: I just shipped a separate experiment, cpkt9762/opencode-vscode-ide
— a VS Code fork (not an extension, not a webview bolt-on) where the
opencode SPA is vendored into the workbench and a dedicated IOpencodeServeManager runs in the Electron main to spawn / health-check /
restart opencode serve as a managed child process.
It doesn't yet do the Docker part you're asking about — IOpencodeServeManager currently spawns the native opencode binary
directly. But the manager interface is the only place that touches the
backend lifecycle, so swapping it to docker run --rm -v "$PWD:/workspace" ghcr.io/anomalyco/opencode:<pinned> serve …
(with the loopback HTTP proxy still doing port forwarding into the
container) would give you exactly the shape you described: VS Code fork as
the native GUI, opencode sandboxed inside a per-project container, no
webview hacks.
Concretely, would the following match what you want?
An opencode.runtime setting: binary (today) | docker (new).
Under docker, the IDE auto-pulls/uses ghcr.io/anomalyco/opencode:<pinned>,
mounts only the current workspace as /workspace, exposes opencode serve
on a stable host port, and injects HTTP Basic auth the same way today's
binary path does.
Network policy is up to you — default --network=host for simplicity vs. --network=bridge with explicit egress allow-listing for hardening.
Happy to track this as a feature issue on the new repo if you'd like to
drive the design — your sandbox/scoping requirements matter more than my
guesses at them.
Good idea! We could potentially provide a Docker image for the web UI part that runs standalone (without VS Code). Would that cover your use case?
There is already that . What we could aim for is a combination of the two so opencode is sandboxed into the project scope directory via the container while using VSCode as its GUI
@cpkt9762 wow! pretty neat stuff. Hope I'm not being insulting or anything but why invent a new IDE/GUI specific for opencode as oppose to a plugin/ ext for VSCode, Atom, Brackets etc. ? I've looked at several options and the one thing not considered is running AI in a sandbox environment with the workspace. To me this is a great advantage as it isolates AI strictly to the workspace. There is also a project dedicated to achieving this.
For now I'm using VSCode and running a docker instance of opencode parallel to the workspace in VSCode terminal. The workflow is a bit detached when executing major commands for project needs (e.g. npm or test driven workflows) and context history and continuation is a bit rugged but it gets the job done.
When I get some time I'm going to see if I can run a workspace stack where opencode communicates with other services thus keeping it functional within the workspace.
I'm not verse with VSCODe extension so not sure I can help in any major way.
Activity
cpkt9762 commentedon Apr 24, 2026
Good idea! We could potentially provide a Docker image for the web UI part that runs standalone (without VS Code). Would that cover your use case?
karneaud commentedon Apr 25, 2026
There is already that . What we could aim for is a combination of the two so opencode is sandboxed into the project scope directory via the container while using VSCode as its GUI
cpkt9762 commentedon Apr 25, 2026
Thanks for the clarification — that's a much sharper framing than my
"standalone web Docker" suggestion, and you're right.
For context on what we're already exploring on the "VS Code as GUI +
decoupled opencode backend" axis: I just shipped a separate experiment,
cpkt9762/opencode-vscode-ide
— a VS Code fork (not an extension, not a webview bolt-on) where the
opencode SPA is vendored into the workbench and a dedicated
IOpencodeServeManagerruns in the Electron main to spawn / health-check /restart
opencode serveas a managed child process.It doesn't yet do the Docker part you're asking about —
IOpencodeServeManagercurrently spawns the nativeopencodebinarydirectly. But the manager interface is the only place that touches the
backend lifecycle, so swapping it to
docker run --rm -v "$PWD:/workspace" ghcr.io/anomalyco/opencode:<pinned> serve …(with the loopback HTTP proxy still doing port forwarding into the
container) would give you exactly the shape you described: VS Code fork as
the native GUI, opencode sandboxed inside a per-project container, no
webview hacks.
Concretely, would the following match what you want?
opencode.runtimesetting:binary(today) |docker(new).docker, the IDE auto-pulls/usesghcr.io/anomalyco/opencode:<pinned>,mounts only the current workspace as
/workspace, exposesopencode serveon a stable host port, and injects HTTP Basic auth the same way today's
binary path does.
--network=hostfor simplicity vs.--network=bridgewith explicit egress allow-listing for hardening.Happy to track this as a feature issue on the new repo if you'd like to
drive the design — your sandbox/scoping requirements matter more than my
guesses at them.
karneaud commentedon Apr 28, 2026
@cpkt9762 wow! pretty neat stuff. Hope I'm not being insulting or anything but why invent a new IDE/GUI specific for opencode as oppose to a plugin/ ext for VSCode, Atom, Brackets etc. ? I've looked at several options and the one thing not considered is running AI in a sandbox environment with the workspace. To me this is a great advantage as it isolates AI strictly to the workspace. There is also a project dedicated to achieving this.
For now I'm using VSCode and running a docker instance of opencode parallel to the workspace in VSCode terminal. The workflow is a bit detached when executing major commands for project needs (e.g. npm or test driven workflows) and context history and continuation is a bit rugged but it gets the job done.
When I get some time I'm going to see if I can run a workspace stack where opencode communicates with other services thus keeping it functional within the workspace.
I'm not verse with VSCODe extension so not sure I can help in any major way.