USe docker

[karneaud]

Can we use docker instead?

[cpkt9762]

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]

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]

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?

1. An opencode.runtime setting: binary (today) | docker (new).
2. 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.
3. 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

[karneaud]

@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.