Skip to content

Respect user-provided OPENCODE_CONFIG_DIR when launching OpenCode workspaces #419

@morpheus9393

Description

@morpheus9393

Summary

CodeNomad exposes an OpenCode workspace setting for environment variables, but a user-provided OPENCODE_CONFIG_DIR is overwritten by CodeNomad when launching an OpenCode workspace.

This prevents OpenCode from using the user's official/global OpenCode config directory, for example:

OPENCODE_CONFIG_DIR=C:\Users\Phoenix\.config\opencode

Instead, the launched OpenCode process receives CodeNomad's bundled config directory:

C:\Users\Phoenix\AppData\Local\CodeNomad\resources\server\dist\opencode-config

Impact

This breaks setups where providers, models, plugins, or other OpenCode settings live in the official OpenCode config directory and are expected to be complemented by project-local configs.

In my case, OpenCode provider/model configuration is present in:

C:\Users\Phoenix\.config\opencode\opencode.jsonc

But CodeNomad launches OpenCode with the bundled config dir instead. The bundled config only contains a minimal schema file and no providers. As a result, plugin/default model references can fail at runtime.

Observed example error:

Session error
Error: ProviderModelNotFoundError
Error: Model not found: openai/gpt-5.4-mini.

The intended configured model was available through the user's actual OpenCode config as a provider-qualified model, e.g.:

codexproxy/gpt-5.4-mini

Reproduction

  1. Configure OpenCode providers/models in the official OpenCode config directory:
C:\Users\Phoenix\.config\opencode\opencode.jsonc
  1. In CodeNomad OpenCode settings, add an environment variable:
OPENCODE_CONFIG_DIR=C:\Users\Phoenix\.config\opencode
  1. Start or recreate a CodeNomad workspace.

  2. Inspect the environment seen by the launched OpenCode process.

Actual Behavior

The launched OpenCode process still sees:

OPENCODE_CONFIG_DIR=C:\Users\Phoenix\AppData\Local\CodeNomad\resources\server\dist\opencode-config

The user-provided value from CodeNomad's Environment Variables UI is ignored/overwritten.

Expected Behavior

If CodeNomad allows users to set OPENCODE_CONFIG_DIR in the UI, that value should be respected when launching OpenCode.

At minimum, one of these should happen:

  • User-provided OPENCODE_CONFIG_DIR wins over CodeNomad's default bundled config dir.
  • CodeNomad blocks OPENCODE_CONFIG_DIR in the UI and clearly explains that it is reserved.
  • CodeNomad provides an explicit setting such as "Use global OpenCode config directory".

Likely Cause

In the installed build, workspaces/manager.js constructs the environment like this:

const environment = {
    ...userEnvironment,
    OPENCODE_CONFIG_DIR: this.opencodeConfigDir,
    CODENOMAD_INSTANCE_ID: id,

Because OPENCODE_CONFIG_DIR is assigned after ...userEnvironment, it always overwrites the value configured in the CodeNomad UI.

The bundled config README also documents that CodeNomad sets OPENCODE_CONFIG_DIR for each OpenCode instance.

Suggested Fix

Let CodeNomad's default value be the fallback, but allow an explicit user-provided environment variable to override it:

const environment = {
    OPENCODE_CONFIG_DIR: this.opencodeConfigDir,
    ...userEnvironment,
    CODENOMAD_INSTANCE_ID: id,

This preserves the bundled CodeNomad config behavior by default while making the Environment Variables UI behave as users expect.

If some internal variables must remain protected, CodeNomad can keep overriding those after ...userEnvironment, but OPENCODE_CONFIG_DIR should either be respected or explicitly disallowed in the UI.

Version / Build Clues

The installed bundled config package reports:

@codenomad/opencode-config 0.15.0-dev-20260508-f8102731

Platform:

Windows

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type
No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions