Support custom providers via ACP

[SteffenDE]

Describe the feature or problem you'd like to solve

Custom providers don't work in --acp mode

Proposed solution

ACP should respect the provider and model set using the COPILOT_PROVIDER_* environment variables. For example:

COPILOT_PROVIDER_BASE_URL=https://openrouter.ai/api/v1 COPILOT_PROVIDER_API_KEY="sk-or-v1-XYZ" COPILOT_MODEL="moonshotai/kimi-k2.6" copilot --acp

Right now, this doesn't seem to have any effect in ACP mode.

Example prompts or workflows

No response

Additional context

No response

[yeelam-gordon]

I dug into the bundled app.js (1.0.42-0 and 1.0.43) and found the root cause + a small fix that I've verified works end-to-end. Sharing in case it speeds things up.

Root cause

In q6e (the ACP agent class) newSession and loadSession, providerConfig is received via this.options.providerConfig (passed from startACPMode / DFa) but never propagated to sessionManager.createSession / getSession. Compare with the interactive REPL path in main, which passes provider: P to Qt.createSession.

In 1.0.43 (pkg/universal/1.0.43/app.js), the relevant lines look like:

// q6e.newSession (~offset 12494639)
let l = await this.sessionManager.createSession({
  sessionId: r,
  clientName: Hxr,
  authInfo: n ?? void 0,
  workingDirectory: e.cwd,
  enableStreaming: true,
  runningInInteractiveMode: true,
  reasoningEffort: a,
  configDir: this.options.settings?.configDir,
  sessionCapabilities: new Set(eYt),
  installedPlugins: this.sessionManager.additionalPlugins.length > 0
    ? this.sessionManager.additionalPlugins
    : void 0,
  // <-- provider is missing here
});

q6e.loadSession has the same omission.

Minimal fix

Add provider: this.options.providerConfig to both calls:

  installedPlugins: this.sessionManager.additionalPlugins.length > 0
    ? this.sessionManager.additionalPlugins
    : void 0,
+ provider: this.options.providerConfig,
});

Two occurrences (one in newSession, one in loadSession).

Bonus bug uncovered while testing

When using a model name that contains : (e.g. Ollama's qwen2.5-coder:9b, OpenRouter's moonshotai/kimi-k2.6 is fine but anything with a colon hits this), the reasoning-effort suffix composer produces strings like capi:qwen2.5-coder:9b:defaultReasoningEffort=high which Nas/xm then mis-parses, throwing Unknown model option key: 9b:defaultReasoningEffort.

Two composers are affected (1.0.43 minified names: V2s at offset ~8126050, and an anonymous one at ~9539104). The fix is to skip appending the reasoning-effort suffix when the model name already contains ::

- function V2s(t,e){let r=`capi:${t}`;return e&&!t.includes("defaultReasoningEffort=")?`${r}:defaultReasoningEffort=${e}`:r}
+ function V2s(t,e){let r=`capi:${t}`;return e&&!t.includes("defaultReasoningEffort=")&&!t.includes(":")?`${r}:defaultReasoningEffort=${e}`:r}

- let c=await ZV(t,l,e,n,o,s);if(c)return`${a}:defaultReasoningEffort=${c}`
+ let c=await ZV(t,l,e,n,o,s);if(c&&!t.includes(":"))return`${a}:defaultReasoningEffort=${c}`

Reasoning effort is a Copilot-cloud concept and isn't applicable to BYOK models anyway, so guarding on !t.includes(":") is a safe fast-path.

Verification

After applying the three patches above to a local copy of app.js:

1. Stood up a tiny capture proxy in front of the BYOK URL that logs every /v1/chat/completions request and forwards to Ollama.
2. Ran copilot --acp --stdio with COPILOT_PROVIDER_BASE_URL=http://127.0.0.1:54605/v1, COPILOT_PROVIDER_TYPE=openai, COPILOT_MODEL=qwen2.5-coder:3b-32k.
3. Drove the ACP protocol with a minimal Node client (initialize → session/new → session/prompt).

Before patch: session/prompt round-trips through GitHub Copilot cloud (model self-identifies as claude-opus-4.6, capture proxy sees zero traffic, outbound TCP from copilot.exe goes to GitHub IPs).

After patch: capture proxy logs POST /v1/chat/completions with model: "qwen2.5-coder:3b-32k" and the full system prompt; Ollama responds and the reply round-trips back through ACP. Outbound TCP from copilot.exe is 127.0.0.1:54605.

Tested on 1.0.42-0 and 1.0.43 on Windows. Same minimal diffs apply in both bundles, only the minified identifier names differ (jks → V2s, wV → ZV).

Happy to send a PR if useful — just point me at where the un-minified source lives. The change is small enough that it could also just be picked up by whoever owns the ACP code.

[yeelam-gordon]

This is a bug, not a feature request — see the analysis and patch in my earlier comment. I've verified the fix locally on 1.0.42-0 and 1.0.43.

[xunilog]

It would be nice that there is more attention going forward to ACP parity with cli, where standards allow. It is starting to be hard to understand which feature is available in VSCode vs Cli vs ACP atm, creating confusion. If VSCode started using ACP as well, no doubt this would move toward coherence.