[awf] api-proxy/Copilot: BYOK COPILOT_PROVIDER_API_KEY never used; adapter falls back to COPILOT_GITHUB_TOKEN

[lpcox]

Problem

When a workflow sets engine: copilot with BYOK vars (COPILOT_PROVIDER_BASE_URL + COPILOT_PROVIDER_API_KEY), the AWF api-proxy Copilot adapter ignores the injected dummy COPILOT_API_KEY (per #3322) and falls back to COPILOT_GITHUB_TOKEN — never consulting COPILOT_PROVIDER_API_KEY. Result: HTTP 503 (if token suppressed) or HTTP 401 (GitHub identity token forwarded to external provider).

Context

Original issue: github/gh-aw#35575

Root Cause

In containers/api-proxy/, the Copilot adapter auth resolution does not check for COPILOT_PROVIDER_API_KEY. When COPILOT_API_KEY is the dummy BYOK sentinel, the adapter should fall through to COPILOT_PROVIDER_API_KEY before trying COPILOT_GITHUB_TOKEN.

Proposed Solution

In the Copilot adapter auth logic (containers/api-proxy/), after determining COPILOT_API_KEY is the dummy sentinel, check COPILOT_PROVIDER_API_KEY and use it as the Authorization: Bearer for the upstream request. Only fall back to COPILOT_GITHUB_TOKEN when COPILOT_PROVIDER_API_KEY is also absent. Add a test asserting BYOK key priority order.

Generated by Firewall Issue Dispatcher · sonnet46 2M · ◷

[lpcox]

Closing — this is already resolved by PR #2598 (merged May 5).

The CLI layer (src/copilot-api-resolver.ts) resolves COPILOT_API_KEY || COPILOT_PROVIDER_API_KEY and injects the result as COPILOT_API_KEY into the api-proxy sidecar container (src/services/api-proxy-service.ts:118). The sidecar's resolveApiKey() then picks it up normally.

So COPILOT_PROVIDER_API_KEY IS used for auth — just indirectly via the CLI's resolution step. The adapter doesn't need to check it directly because by the time the sidecar runs, the resolved value is already in COPILOT_API_KEY.

[zarenner]

Thanks, but I don't think #2598 covers this case — and the verification posted on gh-aw#35575 is the empirical proof. Let me trace exactly where the resolution chain breaks:

Order of operations in the failing run (gh-aw v0.77.5 compiled lock, AWF v0.25.58):

1. gh-aw's pathSetup emits, in the agent step's run: block, before awf is invoked:

   export COPILOT_API_KEY="$COPILOT_DUMMY_BYOK"   # = "dummy-byok-key-for-offline-mode"
   sudo -E awf --config ... --env-all --exclude-env COPILOT_PROVIDER_API_KEY ... copilot ...

2. sudo -E awf inherits that outer-shell env, so AWF's CLI starts with COPILOT_API_KEY=dummy-byok-key-for-offline-mode and COPILOT_PROVIDER_API_KEY=<real Azure key>.
3. src/copilot-api-resolver.ts runs COPILOT_API_KEY || COPILOT_PROVIDER_API_KEY. The dummy is truthy, so || short-circuits and returns the dummy. COPILOT_PROVIDER_API_KEY is never consulted.
4. AWF injects that resolved value (the dummy) into the sidecar as COPILOT_API_KEY. The sidecar's resolveApiKey() picks up the dummy and forwards it upstream → 503.

So PR #2598's resolver is on the code path, it just gets a poisoned input. The fallback in A || B only fires when A is falsy, and A is never falsy in BYOK mode after the dummy sentinel was introduced upstream.

Two ways to actually close this:

• Smallest fix (AWF side): teach copilot-api-resolver.ts that the dummy sentinel means "unset," and prefer COPILOT_PROVIDER_API_KEY when present:

  const clean = (v?: string) => (v && v !== COPILOT_BYOK_DUMMY_API_KEY ? v : undefined);
  const key = clean(process.env.COPILOT_PROVIDER_API_KEY)
           ?? clean(process.env.COPILOT_API_KEY)
           ?? clean(process.env.COPILOT_GITHUB_TOKEN);

  One-file change; immediately unblocks every freshly compiled gh-aw lock without any gh-aw release.
• Or (gh-aw side): stop `export`-ing the dummy into the outer shell at all — pass it only into the agent container via a scoped env flag, so it never reaches AWF's resolver in the first place.

Happy to open a PR against either repo if you'd like — but until one of those lands, the closure is empirically incorrect: the run that succeeded in the linked verification is only succeeding because the lock file was sed-patched to bypass the dummy assignment. Could you reopen?