Authorization header still malformed for api.business.githubcopilot.com on GHES at AWF v0.27.31 (fix in #5415 doesn't appear to cover this target)

[jaroslawgajewski]

Context: GitHub Enterprise Server instance with Copilot Business licensing. Our gh-aw workflows set --copilot-api-target api.business.githubcopilot.com (Business endpoint, not api.enterprise.githubcopilot.com).

History: The original report (#38575) was closed when #5415 merged (AWF v0.27.9), which added copilotTargetRequiresGitHubTokenPrefix() returning true for api.business.githubcopilot.com on *.ghe.com — supposedly our exact scenario. Two earlier partial fixes (#4755 in v0.27.2, #5076 in v0.27.4) only covered api.enterprise.githubcopilot.com and missed this.

Re-tested twice, both fail identically:

• 2026-06-29 → 2026-07-02, native AWF v0.27.13/v0.27.16, every sampled failure showing "400: Authorization header is badly formatted."
• 2026-07-14, fresh workflow_dispatch test on AWF v0.27.31 (current latest): same signature. Copilot CLI harness exhausts all 4 retries, each returning 400 400 400 Bad Request. Firewall audit confirms the request reaches api.business.githubcopilot.com cleanly (11 allowed / 0 denied — not a domain-block, an application-layer rejection from the real endpoint).

Ask: Please confirm whether copilotTargetRequiresGitHubTokenPrefix()'s current logic actually matches our configuration (GHES + Business licensing + explicit --copilot-api-target), since the symptom is unchanged from before the fix through the current latest release. We currently work around this by pinning AWF to v0.25.55 indefinitely.

Evidence available on request: run IDs, timestamps, redacted logs.

[jaroslawgajewski]

We found the actual cause of that symptom was self-inflicted: our own post-compile patch injected a COPILOT_PROVIDER_API_KEY placeholder (placeholder-token-for-credential-isolation) that doesn't match the literal sentinel resolveApiKey() checks for ('ghu_' + 'a'.repeat(36) in containers/api-proxy/providers/copilot-byok.js). An unrecognized placeholder is treated as a real BYOK key, which silences the token-prefix logic in copilot.js ((requiresGitHubTokenPrefix && !apiKey) ? 'token' : 'Bearer') and sends the placeholder text itself as the credential. We confirmed this precisely by cloning this repo and simulating our exact environment through the real resolver functions — copilotTargetRequiresGitHubTokenPrefix() itself was correct all along. We've fixed our placeholder value and are not asking anything further about that part.

What's left is a real, distinct problem, found while live-testing the placeholder fix on AWF v0.27.31 (fresh workflow_dispatch, GHES, Copilot engine, offline+BYOK mode, which our GHES deployment's compiled workflows use for reasons unrelated to this report):

With the corrected placeholder, AWF's own health-check now correctly logs COPILOT_PROVIDER_API_KEY is placeholder value (correct) and unsets it from the parent shell environment per containers/agent/entrypoint.sh's unset_sensitive_tokens(). But that function is called from run_agent_with_token_protection() after backgrounding the agent process and waiting (up to 1s, polling every 100ms) for it to start — by which point the Copilot CLI has already forked with its own inherited copy of the unsanitized COPILOT_PROVIDER_API_KEY (the placeholder string, verbatim). Because the workflow is in offline+BYOK mode (COPILOT_PROVIDER_BASE_URL pointing at the local api-proxy sidecar), the CLI then uses this same placeholder as its own bearer credential when authenticating to that local sidecar — a completely different hop from the one resolveApiKey()/copilotTargetRequiresGitHubTokenPrefix() govern (those decide what the sidecar sends upstream; they have no bearing on how the CLI authenticates to the sidecar). The sidecar (or a relay behind it) rejects the placeholder, and the CLI reports:

Authentication failed with provider at http://172.30.0.30:10002 (HTTP 401).
Check your COPILOT_PROVIDER_API_KEY or COPILOT_PROVIDER_BEARER_TOKEN.
This is a version-specific regression, not an inherent design limitation. Our production workflows, still pinned to AWF v0.25.55, compile into the exact same offline+BYOK pattern (COPILOT_DUMMY_BYOK: dummy-byok-key-for-offline-mode + a COPILOT_PROVIDER_API_KEY placeholder — currently still our own unrecognized one) and run successfully today. So whatever handles the CLI→sidecar hop evidently works differently, or has different timing, between v0.25.55 and v0.27.31 — we could not pin down the exact change without diffing the actual AWF releases' runtime behavior across that range (out of scope for source reading alone).

Ask:

Either close the timing gap so the agent process only forks after the real credential is available for its one required read (rather than relying on a race against a 1-second poll loop), or give the offline+BYOK/local-proxy path its own dedicated, freshly-generated local session credential that isn't the same value used for upstream credential-isolation decisions.
Confirm whether anything about the CLI→sidecar local-auth path changed between v0.25.x and v0.27.x — if so, that's likely the actual regression to fix.
Separately (unrelated to the above): endpoint auto-derivation still ignores Copilot licensing tier — AWF auto-derives copilot-api..ghe.com from GITHUB_SERVER_URL on .ghe.com hosts when --copilot-api-target/COPILOT_API_TARGET is unset, which is wrong for Business-licensed orgs (need api.business.githubcopilot.com explicitly). We still override this on every Copilot workflow.