Repository navigation
[FEATURE]: Allow plugins to register custom WorkspaceDriver providers #45612
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
We’re exploring OpenCode v2 support for Fly.io Sprites, where each OpenCode workspace would run inside a remote Sprite.
The new WorkspaceDriver abstraction appears to be a strong fit: a provider can provision a workspace, connect it to an environment driver, suspend it when idle, and destroy it. This would let OpenCode route shell and filesystem operations directly to a remote sandbox.
The current challenge is registration. workspaceProviders can be supplied when creating an embedded Effect SDK host, but it is not exposed through the v2 plugin API, and the Promise SDK omits that host option. As a result, third-party workspace drivers currently require replacing or custom-embedding the OpenCode host.
Would you consider exposing a supported extension point for registering workspace providers from packages or plugins? For example:
export default Plugin.define({
id: "sprites",
setup(ctx) {
ctx.workspace.register("sprites", spritesWorkspaceDriver)
},
})
Alternatively, workspace providers could be loaded from a dedicated configuration section:
{
"workspaceProviders": {
"sprites": {
"package": "@flydotio/opencode-sprites"
}
}
}
The provider would implement the existing lifecycle contract:
interface WorkspaceDriver {
create(input): Promise<{ binding: unknown }>
connect(input): Promise<EnvironmentDriver>
suspendForIdle(input): Promise<void>
destroy(input): Promise<void>
}
This would enable Sprites and other remote sandbox systems—containers, VMs, cloud development environments, and ephemeral CI environments—without requiring each provider to ship a custom OpenCode server.
We’d be happy to prototype the Sprites driver and provide feedback on the extension API. Is package-level WorkspaceDriver registration something you would be open to supporting?
Activity
BleedingCodes commentedon Oct 17, 2026
I built Spine, an experimental OpenCode integration exploring durable memory, context assembly, evidence, and crash recovery. It uses the route-level overrides seam from #41918; I reproduced the pass-through Bus test against dev commit 86c7f7c and got S0 ACCEPTED.
This is broader than WorkspaceDriver registration, so I don’t want to expand this issue. Would you prefer a separate feature request about the general embedding/service-replacement path? I also saw #50185, which seems related to replaceable LLM execution.
remorses commentedon Oct 24, 2026
+1, same need from Kimaki (Discord frontend for OpenCode).
Today I run a separate OpenCode on each machine, so every machine has its own global AGENTS.md, config and auth to keep in sync. I'd rather run one OpenCode service and place sessions on other Macs or sandboxes through a workspace driver (SSH, Sprites, etc).
Besides plugin-registered drivers, this also needs a public way to create a session in a workspace (
session.createwith aworkspaceID), see #39614.opencodejr commentedon Oct 28, 2026
Thanks for the detailed proposal, and for offering to prototype a Sprites driver!
To restate it: you'd like a supported way for packages or plugins to register custom
WorkspaceDriverproviders, through either a plugin API likectx.workspace.register(...)or a config section. That way remote sandboxes such as Sprites could plug in without a custom OpenCode host.You're right about the current state.
workspaceProviderscan only be passed to the embedded Effect SDK host, the Promise SDK leaves it out, and the v2 plugin API has no workspace registration point. So a plugin can't do this today. Maintainers will consider adding an extension point for it.Related issues and PRs:
workspaceProvidersoption that this would build onphanex commentedon Oct 29, 2026
Another use case distinct from cloud sandboxes like Sprites: using the local workstation as the execution target.
Here, the server hosts the persistent state (projects, session history, agents, and skills), while the desktop app on the local machine acts as the "hands" for a specific folder, for example
my projects/project1. One project could have multiple workspaces attached over time (desktop, laptop, server).When the local machine disconnects, the session stays accessible on the server in read-only / chat mode. File access and command execution simply fail cleanly with an offline state instead of hallucinating.
Existing remote setups (VS Code Remote, or OpenCode with a remote server today) do the mirror image: local UI, remote execution. The missing piece is keeping the durable brain on a central server while executing locally on the machine in front of you.