Repository navigation
[FEATURE]: Base path / prefix routing support #7624
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
Use case
We'd like to integrate OpenCode as a feature into larger platforms, where it runs under a URL prefix (e.g., platform.com/opencode/) rather than at the root path.
Request
Add support for a configurable base path so OpenCode can be embedded into existing platforms and served alongside other applications under the same domain.
Reacted by André König, Link, HongboDu-at, Sam Roehrich, Pretzel Vector, Łukasz Biegaj, naiba, Leonidas, Bryan Peterson, Daeho Yang and 45 more
Reacted by Gabriel Meola, Nikitas Rontsis, Nat Welch and Celestial.y
Metadata
Metadata
Assignees
Labels
No labels
Activity
github-actions commentedon Jan 10, 2026
This issue might be a duplicate of or related to existing issues. Please check:
opencodebinary. #6352: allow overriding web client deployment path / bundle web client withopencodebinary - discusses deployment configuration and serving from non-root pathsThese issues touch on similar aspects of URL configuration and hosting OpenCode in larger platforms. Feel free to ignore if your specific use case isn't covered by these.
LeonMueller-OneAndOnly commentedon Feb 21, 2026
For the usage with tailscale this would also be a very nice feature, so one can expose multiple services from one machine over tailscale.
I am referring to this feature of tailscale serve:
--set-path= Appends the specified path to the base URL for accessing the underlying service.
https://tailscale.com/docs/reference/tailscale-cli/serve
Ark-kun commentedon Mar 19, 2026
I was doing similar work and I might have found a simple way (just 7 lines of code) to get most of that via VITE_BASE_URL. Would you mind taking a look? #18209
It does something a bit different - it bakes the prefix during the build. But this also makes it very easy to change at runtime or even via proxy. For example, you can set
VITE_BASE_URL="XXX_OPENCODE_BASE_URL_XXX"and then even a transparent proxy can dynamically replace it on the fly as it serves compiled JS files.PhantomYdn commentedon Mar 20, 2026
This feature being raised in multiple issues. I have solved it there: https://github.com/SkyNetCMS/opencode
This fork has 2 main features:
This fork is needed for the SkyNetCMS: CMS where opencode is embedded into webpage. Like https://lovable.dev/ but fully opensource.
solarkraft commentedon Apr 23, 2026
It would be great to have this integrated. Would make it much easier for me to host my self maintained fork.
solarkraft commentedon Apr 29, 2026
Oh, it turns out that #21243 was actually merged (Github just shows it badly)! Nice one!
Edit: I was wrong :(
solarkraft commentedon May 6, 2026
I have tested #18209 and it works great, both in development and build. It's a tiny change and perfectly fulfills my use case - better than the dynamic version since I am hosting the front-end statically, independent of the API server.
fabiovincenzi commentedon May 19, 2026
I've opened #28326 which adds runtime
--base-pathsupport (CLI flag + config) without needing to rebuild the frontend. It covers server-side prefix stripping, HTML injection with CSP support, and relative asset paths viabase: "./"in Vite.gitZhuo commentedon Jul 17, 2026
We are affected by this in a real enterprise deployment.
Our public gateway only permits applications under
/web/*, so OpenCodemust be exposed at:
https://test.abc.com/web/oc/
nginx strips
/web/oc/and proxies requests to:http://10.0.0.1:4096/
However,
opencode webgenerates origin-root URLs such as:/assets/*/event/health/config/project/global/event/session/*/pty/*These requests bypass
/web/oc/and are rejected by the gateway.Using nginx
sub_filteris fragile because it requires rewriting minifiedJavaScript, API paths, SSE endpoints, WebSocket endpoints, dynamic imports,
and frontend navigation routes.
A first-class option such as the following would solve this:
opencode web \ --hostname 0.0.0.0 \ --port 4096 \ --base-path /web/oc Or configuration: { "server": { "basePath": "/web/oc" } } Expected behavior: 1. Static assets use /web/oc/assets/*. 2. HTTP APIs use /web/oc/*. 3. SSE and WebSocket URLs include the prefix. 4. Client-side navigation preserves the prefix. 5. Direct navigation and refresh under /web/oc/... work. 6. X-Forwarded-Prefix: /web/oc may optionally be honored. 7. Root deployments remain backward compatible. A dedicated hostname or root-path deployment is not possible in our environment, so native base-path support is required.SmokinCaterpillar commentedon Aug 23, 2026
I would really like to have this integrated, would make our work also easier!
gitZhuo commentedon Aug 23, 2026
icco commentedon Sep 30, 2026
Would love for this to be merged.
gitZhuo commentedon Sep 30, 2026
opencodejr commentedon Oct 29, 2026
Thanks for the request, @hsteude!
To restate it: you'd like a configurable base path, so the OpenCode server and web UI can be served under a URL prefix like
platform.com/opencode/behind a reverse proxy, alongside other apps on the same domain.As far as I can tell, OpenCode currently expects to be served from the root path, and a plugin can't change that, because the prefix would have to apply to the server's routes and to how the web app loads its assets. This would need to be added in OpenCode itself. Maintainers will consider it.
gitZhuo commentedon Oct 29, 2026
fabiovincenzi commentedon Nov 4, 2026
I've ported #28326 to V2 in #61624.
opencode serve --base-path /opencodeserves the API and the web app under a path prefix, and the PR adds a docs section with an nginx example.It's a draft until #60559 (the client-side part) is merged.