Sandboxed Copilot workflows should set responses wire API for GPT-5 models in BYOK/offline mode

[trask]

Summary

Sandboxed engine: copilot workflows can fail with newer GPT-5-family models because the compiler forces Copilot BYOK/offline behavior in AWF mode, but does not appear to set COPILOT_PROVIDER_WIRE_API=responses when the selected COPILOT_MODEL requires the responses API.

Source-backed root cause

Latest github/gh-aw intentionally makes Copilot BYOK behavior the default for sandboxed Copilot workflows:

• pkg/workflow/copilot_engine_execution.go injects COPILOT_API_KEY: dummy-byok-key-for-offline-mode when the AWF sandbox is enabled.
• The same code avoids injecting this dummy key when sandbox.agent: false, because no api-proxy is available and the key would break Copilot CLI authentication.
• pkg/constants/feature_constants.go documents that features.byok-copilot is deprecated because the compiler now always injects the dummy key for Copilot BYOK behavior.
• docs/src/content/docs/reference/frontmatter.md documents the default BYOK behavior for engine: copilot.

Latest github/gh-aw-firewall then treats the presence of a Copilot API key as the signal to configure Copilot CLI in offline/BYOK mode:

• src/services/api-proxy-service.ts sets COPILOT_API_URL to the sidecar.
• When copilotApiKey is present, it sets COPILOT_OFFLINE=true, COPILOT_PROVIDER_BASE_URL to the sidecar, and placeholder provider credentials in the agent environment.
• containers/api-proxy/providers/copilot.js forwards Copilot traffic through the sidecar and uses the GitHub OAuth token specially for /models.

This is intentional and useful, but it changes model routing semantics: the Copilot CLI is no longer using its normal GitHub Copilot backend negotiation path. The docs for Copilot BYOK mode say COPILOT_PROVIDER_WIRE_API defaults to completions, and responses is needed for GPT-5 series models.

I could not find compiler logic that derives COPILOT_PROVIDER_WIRE_API=responses from a GPT-5-family COPILOT_MODEL.

Expected behavior

For sandboxed engine: copilot workflows, when the selected model requires the responses API, the compiled workflow should configure Copilot BYOK/offline mode with the appropriate wire API, for example:

COPILOT_PROVIDER_WIRE_API: responses

or otherwise preserve the Copilot CLI's normal model/routing negotiation.

Actual behavior

The compiler activates Copilot BYOK/offline behavior for sandboxed workflows via the dummy COPILOT_API_KEY, but only sets COPILOT_MODEL. If that model is a GPT-5-family model, the Copilot CLI appears to use the default BYOK wire API (completions) instead of responses, which blocks those models unless the workflow disables the AWF sandbox or manually configures the provider wire API.

Why this matters

Downstream workflows currently need to disable sandbox.agent to let Copilot CLI connect directly to api.githubcopilot.com and negotiate the newer model routing. That also disables AWF-dependent features such as safe-output threat detection, so the workaround weakens the workflow's security posture.

Possible fix

Teach the compiler to set COPILOT_PROVIDER_WIRE_API=responses when COPILOT_MODEL is statically known to be a GPT-5-family model, or provide a documented frontmatter-level option that emits the necessary provider env var without requiring users to hand-wire BYOK internals.

For dynamic model expressions such as ${{ vars.MY_MODEL || 'gpt-5' }}, consider using the fallback literal to infer the wire API when possible, or document that users must set engine.env.COPILOT_PROVIDER_WIRE_API: responses.

[lpcox]

🔗 AWF tracking issue: https://github.com/github/gh-aw-firewall/issues/github/gh-aw-firewall#2802

Generated by Firewall Issue Dispatcher · ● 876.2K · ◷

[lpcox]

🔗 AWF tracking issue: https://github.com/github/gh-aw-firewall/issues/github/gh-aw-firewall#2832

Generated by Firewall Issue Dispatcher · ● 545.2K · ◷