Skip to content

opencode acp mode ignores OPENCODE_CONFIG_CONTENT and OPENCODE_CONFIG_DIR #34638

Closed as not planned

Description

@Nnyan

Description

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

  1. Write a custom opencode.json in a temp directory with a custom OpenAI-compatible provider
  2. Set OPENCODE_CONFIG_DIR=/tmp/custom-config or OPENCODE_CONFIG_CONTENT='{...}'
  3. Launch opencode acp, send initialize → session/new → session/prompt
  4. Observe that requests go to the default config provider, NOT the override

Expected Behavior

  • OPENCODE_CONFIG_CONTENT should override provider config in ACP mode (same as CLI/TUI mode)
  • OPENCODE_CONFIG_DIR should allow specifying a custom config directory

Actual Behavior

  • Both env vars are ignored in ACP mode
  • ACP reads only the on-disk ~/.config/opencode/opencode.json and working-directory opencode.json

Environment

  • opencode 1.17.11
  • Linux

Impact

This blocks Charon (https://github.com/SLOP-Platform/charon) from launching per-run observer proxies for telemetry — the ACP subprocess always routes through the user's configured provider instead of the tooling's proxy.

Workaround

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.

Activity

  1. github-actions commented on Jun 30, 2026

    @github-actions
    Contributor

    This issue might be a duplicate of existing issues. Please check:

  2. Nnyan commented on Jul 1, 2026

    @Nnyan
    Author

    Empirical verification (2026-06-30, opencode 1.17.11, Linux)

    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.

  3. Nnyan commented on Jul 1, 2026

    @Nnyan
    Author

    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.

  4. nexxeln commented on Jul 1, 2026

    @nexxeln
    Contributor

    i couldnt reproduce this on latest/dev

  5. github-actions commented on Aug 31, 2026

    @github-actions
    Contributor

    To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions