You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
opencode acp mode ignores OPENCODE_CONFIG_CONTENT and OPENCODE_CONFIG_DIR #34638
opencode acp mode does not honor OPENCODE_CONFIG_CONTENT or OPENCODE_CONFIG_DIR for provider configuration. This prevents tooling that launches opencode as an ACP subprocess from wiring it to a per-run proxy or custom provider.
Steps to Reproduce
Write a custom opencode.json in a temp directory with a custom OpenAI-compatible provider
Set OPENCODE_CONFIG_DIR=/tmp/custom-config or OPENCODE_CONFIG_CONTENT='{...}'
None. Both OPENCODE_CONFIG_CONTENT and OPENCODE_CONFIG_DIR fail. The only option would be to modify the user's on-disk config before launching ACP, which is a race condition.
This issue might be a duplicate of existing issues. Please check:
opencode serve ignores configuration #19078: opencode serve also ignores configuration env vars (OPENCODE_CONFIG/provider config) — same class of problem where a non-TUI mode bypasses env-based config overrides.
Reproduced with a test listener on a random loopback port:
OPENCODE_CONFIG_CONTENT env var: NOT honored ✅ (confirms the issue)
OPENCODE_CONFIG env var (file path): NOT tested but likely same code path
cwd opencode.json: IS honored ✅ (new finding)
The cwd opencode.json test: wrote a custom provider config to <cwd>/opencode.json, launched opencode acp with all override env vars stripped. The agent resolved the custom provider (session/new returned currentValue: "charon_probe/cpt") and routed 2 API calls through the test listener. Full trace available.
Impact update
There IS a workaround for Charon/SLOP-Platform/charon: write per-run opencode.json into the ACP subprocess cwd (Charon already controls the worktree cwd for each ACP subprocess). This unblocks the per-run-proxy routing approach without mutating the user global config.
Correction suggestion
The issue title mentions OPENCODE_CONFIG_DIR. That env var points at a resource directory (agents/commands/plugins/skills scanning), not a config file path. The correct env var for a config file override is OPENCODE_CONFIG (Flag.OPENCODE_CONFIG). Recommend updating the title accordingly.
Root cause (per architecture analysis)
ACP is a separate entry point (packages/opencode/src/acp/agent.ts) from CLI/TUI. It resolves config independently and never calls resolveNetworkOptions() in packages/opencode/src/cli/network.ts. PR #23318 adds getGlobalWithOverrides() to fix serve/web — the same pattern needs wiring into the ACP agent path.
Update: found a workaround. While OPENCODE_CONFIG_CONTENT is ignored by opencode acp, the subprocess DOES honor a per-run opencode.json in its current working directory. By writing the config to the worktree and launching opencode acp from there, we can inject per-run provider overrides.
Tested working on opencode 1.17.11 Linux. The cwd config approach resolves the immediate blocker, but the root cause (ACP mode skipping the standard config initialization) should still be fixed for robustness.
Activity
github-actions commentedon Jun 30, 2026
This issue might be a duplicate of existing issues. Please check:
opencode servealso ignores configuration env vars (OPENCODE_CONFIG/provider config) — same class of problem where a non-TUI mode bypasses env-based config overrides.Nnyan commentedon Jul 1, 2026
Empirical verification (2026-06-30, opencode 1.17.11, Linux)
Reproduced with a test listener on a random loopback port:
OPENCODE_CONFIG_CONTENTenv var: NOT honored ✅ (confirms the issue)OPENCODE_CONFIGenv var (file path): NOT tested but likely same code pathopencode.json: IS honored ✅ (new finding)The cwd
opencode.jsontest: wrote a custom provider config to<cwd>/opencode.json, launchedopencode acpwith all override env vars stripped. The agent resolved the custom provider (session/newreturnedcurrentValue: "charon_probe/cpt") and routed 2 API calls through the test listener. Full trace available.Impact update
There IS a workaround for Charon/SLOP-Platform/charon: write per-run
opencode.jsoninto the ACP subprocess cwd (Charon already controls the worktree cwd for each ACP subprocess). This unblocks the per-run-proxy routing approach without mutating the user global config.Correction suggestion
The issue title mentions
OPENCODE_CONFIG_DIR. That env var points at a resource directory (agents/commands/plugins/skills scanning), not a config file path. The correct env var for a config file override isOPENCODE_CONFIG(Flag.OPENCODE_CONFIG). Recommend updating the title accordingly.Root cause (per architecture analysis)
ACP is a separate entry point (
packages/opencode/src/acp/agent.ts) from CLI/TUI. It resolves config independently and never callsresolveNetworkOptions()inpackages/opencode/src/cli/network.ts. PR #23318 addsgetGlobalWithOverrides()to fixserve/web— the same pattern needs wiring into the ACP agent path.Nnyan commentedon Jul 1, 2026
Update: found a workaround. While
OPENCODE_CONFIG_CONTENTis ignored byopencode acp, the subprocess DOES honor a per-runopencode.jsonin its current working directory. By writing the config to the worktree and launchingopencode acpfrom there, we can inject per-run provider overrides.Tested working on opencode 1.17.11 Linux. The cwd config approach resolves the immediate blocker, but the root cause (ACP mode skipping the standard config initialization) should still be fixed for robustness.
nexxeln commentedon Jul 1, 2026
i couldnt reproduce this on latest/dev
github-actions commentedon Aug 31, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.