feat(server): expose opencode server proxy url env

[pascalandr]

Fixes #321

Summary

• expose OPENCODE_SERVER_BASE_URL in the spawned OpenCode workspace environment
• point it at the current workspace's stable CodeNomad proxy URL
• propagate the new variable through WSL launches alongside the existing auth env vars

Why

Tools and plugins already receive the auth credentials needed to call the current workspace instance, but they still need an extra lookup to discover the correct URL.

The proxy URL is already known before runtime startup, so exposing it directly removes that lookup without changing OpenCode's port selection flow.

What Changed

• packages/server/src/workspaces/opencode-auth.ts: added the OPENCODE_SERVER_BASE_URL env var constant
• packages/server/src/workspaces/manager.ts: injects OPENCODE_SERVER_BASE_URL into the workspace runtime environment using CODENOMAD_BASE_URL + proxyPath
• packages/server/src/workspaces/tests/spawn.test.ts: updates WSL env propagation coverage for the new variable

Validation

• npx tsx --test "packages/server/src/workspaces/tests/spawn.test.ts"

[pascalandr]

@CodeNomadBot

I want you to perform the gatekeeper checks for latest PR state

check for regressions
check for better possible implementations
Be the PR gatekeeper
Be ruthless about code quality

[codenomadbot]

Gatekeeper review for the latest PR state.

What I reviewed

• packages/server/src/workspaces/opencode-auth.ts
• packages/server/src/workspaces/manager.ts
• packages/server/src/workspaces/__tests__/spawn.test.ts
• PR diff against origin/dev

What I understood the request to be

• Review the current PR state for regressions
• Look for stronger implementation choices
• Be strict about code quality and call out blockers if present

Findings

• No blocking findings in the current diff.

Why this looks sound

• OPENCODE_SERVER_BASE_URL is introduced as a dedicated constant instead of hardcoding the string in manager.ts.
• manager.ts builds the new env var from the already-known stable proxy path and trims trailing slashes first, which avoids malformed //workspaces/... URLs.
• The existing CODENOMAD_BASE_URL behavior is preserved, so this is additive rather than a behavioral rewrite.
• WSL propagation was updated in the existing spawn coverage where this would most likely regress on Windows.

Validation

• Ran npx tsx --test "packages/server/src/workspaces/__tests__/spawn.test.ts"
• Result: passing

Non-blocking quality note

• I do not see a direct WorkspaceManager test asserting that the launched environment includes OPENCODE_SERVER_BASE_URL with the expected ${serverBaseUrl}${proxyPath} value. The current spawn test covers WSL propagation, but not the manager-side assembly itself. I would treat that as a follow-up hardening improvement rather than a merge blocker for this PR.

Gatekeeper verdict

• No regression found in the reviewed change set.
• No better implementation required for merge based on the current scope.
• Residual risk is limited to missing direct manager-level coverage for env construction.

--
Yours,
CodeNomadBot

[shantur]

@pascalandr - Would you be able to tell me the usecase for this?
We already have CODENOMAD_BASE_URL isn't it?
If the requirement is for a plugin got talk to CodeNomad then exisiting base URL can be used
If the requirement for the plugin is to talk Opencode then the plugin internal client can be used.

[pascalandr]

This is mainly for tools running inside OpenCode, not plugin code.
I agree it is mostly a convenience If you'd rather keep the env smaller, I'm fine closing this but the path needs documenting.

[shantur]

This is mainly for tools running inside OpenCode, not plugin code.

Why does tools like (bash, edit, apply_patch ) need access to CodeNomad base url?

[github-actions]

PR builds are available as GitHub Actions artifacts:

https://github.com/NeuralNomadsAI/CodeNomad/actions/runs/24960350917

Artifacts expire in 7 days.
Artifacts: (none found on this run)

[pascalandr]

This is mainly for tools running inside OpenCode, not plugin code.

Why does tools like (bash, edit, apply_patch ) need access to CodeNomad base url?

Well this is the issue :

It would be handy to have the OpenCode server URL easily available in the OpenCode environment. For me personally I'm making API calls from tools and plugins to the OpenCode server to accomplish things that aren't currently supported by their plugin architecture. Being able to identify the "correct" OpenCode server to talk to is important for this use case.

✔️ You already provide OPENCODE_SERVER_USERNAME and OPENCODE_SERVER_PASSWORD in the environment. ❌ The OpenCode server port is not available in the environment.

Request: Add something like OPENCODE_SERVER_BASE_URL with the full URL and/or OPENCODE_SERVER_PORT with the port number in the environment.

[shantur]

opencode plugins don't need the port to call API calls to opencode.

We already have codenomad base url and opencode instance id but If your requirement is opencode specific and if below doesn't help, we can add the port

Plugin

In a server plugin, use the serverUrl that OpenCode passes in PluginInput:

• input.serverUrl is a URL (includes host + port).
• input.serverUrl.port gives you the port as a string.

This comes from packages/opencode/src/plugin/index.ts:

• get serverUrl(): URL { return Server.url ?? new URL("http://localhost:4096") }

So if the server is actually listening, Server.url will be set (in packages/opencode/src/server/server.ts during listen()), and your plugin sees the real port. If OpenCode is running in a mode where the server isn’t listening (only app.fetch), there is no real port, and you’ll get the fallback 4096.

Bash Tool

Yes, the bash tool can figure it out, but there’s no first-class “give me server port” API. Practically you can:

1. Use the OPENCODE_PID environment variable (it’s set at process startup) and inspect listening sockets for that PID.
2. Or just search for a listening opencode process.

Examples (macOS):

lsof -nP -p "$OPENCODE_PID" -iTCP -sTCP:LISTEN

or:

lsof -nP -iTCP -sTCP:LISTEN | rg -i 'opencode|bun'

This works because the bash tool inherits process.env (see packages/opencode/src/tool/bash.ts, shellEnv() merges ...process.env).

[pascalandr]

Right, and that workaround is exactly what @TheStaticMage is using today. This issue is really just a convenience request.
The point of this PR is only to expose the already-known resolved URL directly, so tools do not need an extra lookup or manual path reconstruction. I do not see much harm in that, but I am also fine closing this PR and #321 if we do not think the convenience justifies the extra env surface.

[shantur]

@pascalandr - Can we change it to OPENCODE_SERVER_PORT in that case, it will be more targetted to OpenCode

[pascalandr]

Just to confirm before I change the PR: do you mean a straight rename of the current env var shape, or do you want to also change the PR to expose only the actual OpenCode port value instead of the resolved proxy URL?

[shantur]

Just to confirm before I change the PR: do you mean a straight rename of the current env var shape, or do you want to also change the PR to expose only the actual OpenCode port value instead of the resolved proxy URL?

I am thinking to just expose the OPENCODE_PORT as to be able to connect to opencode username, password and port are needed and port is the missing piece of the puzzle.