OPENCODE_CONFIG_DIR is treated as an exclusive user config root, unlike OpenCode's additive directory semantics

[jollyxenon]

Summary

When OPENCODE_CONFIG_DIR is set, OMO appears to treat it as the only user-level OpenCode config root.

This differs from OpenCode's current documented/runtime behavior, where OPENCODE_CONFIG_DIR is treated as an additional custom directory / override layer rather than a full replacement for the default global config path.

As a result, if a host app sets OPENCODE_CONFIG_DIR to inject its own plugin/config directory, OMO can no longer see user-level OMO config that still lives under the default OpenCode global path.

What I observed

In my case, a host app (CodeNomad) launches OpenCode with OPENCODE_CONFIG_DIR pointing at its packaged config directory so that OpenCode auto-loads a bundled bridge plugin.

OpenCode itself still loads correctly, but OMO loses access to user-level config such as:

• ~/.config/opencode/oh-my-openagent.json / .jsonc
• user-level OMO agents / skills / commands that are resolved via OMO's OpenCode config dir helpers

The visible symptom was that the OMO agent set shrank when OPENCODE_CONFIG_DIR was set, because OMO could no longer find the user's existing OMO config/model mappings from the default global OpenCode config path.

Why this looks like an OMO-side incompatibility

OpenCode docs currently describe OPENCODE_CONFIG_DIR as a custom directory loaded after global config / .opencode directories.

In OMO, however, the config-dir helper uses exclusive selection:

function getCliConfigDir(): string {
  const envConfigDir = process.env.OPENCODE_CONFIG_DIR?.trim()
  if (envConfigDir) {
    return resolveConfigPath(envConfigDir)
  }

  const xdgConfig = process.env.XDG_CONFIG_HOME || join(homedir(), ".config")
  return resolveConfigPath(join(xdgConfig, "opencode"))
}

This means:

• if OPENCODE_CONFIG_DIR is set, OMO returns only that path
• it does not also consider the default global OpenCode path

Downstream impact inside OMO

From reading the source, this resolved directory is then reused by downstream OMO loaders, for example:

• plugin config loading (oh-my-openagent.json/jsonc)
• OpenCode config-based agent loading
• command / skill directory resolution
• other user-level OpenCode/OMO assets that depend on getOpenCodeConfigDir()

So the incompatibility is not just at one entrypoint; it propagates through multiple user-level loading paths.

Expected behavior

I would expect OMO to stay compatible with OpenCode's current additive directory semantics.

Concretely, when OPENCODE_CONFIG_DIR is set, OMO should probably either:

1. search both:
   • the default global OpenCode config dir (for example ~/.config/opencode)
   • the custom OPENCODE_CONFIG_DIR
2. or otherwise adopt the same effective directory search semantics OpenCode itself uses for user-level config discovery

Project-level .opencode discovery appears to be a separate path and is not the main problem here.

Repro outline

1. Put working OMO user config under the default global OpenCode config dir
2. Start OpenCode normally -> OMO sees the expected config/agents
3. Start OpenCode via a host app that sets OPENCODE_CONFIG_DIR to another directory
4. OMO now resolves only that directory and stops seeing the user-level config from the default global path

Question

Would you consider aligning OMO's user-level OpenCode config discovery with OpenCode's additive OPENCODE_CONFIG_DIR semantics?

If useful, I can also provide a smaller isolated reproduction focused only on OMO + OpenCode without the host app in the middle.