BTW side-questions now work in Copilot sessions

ngutman

·Apr 10, 2026·#64275fix(auth): apply copilot runtime auth to /btw

A fix ensures the /btw command works correctly in GitHub Copilot sessions that require runtime auth exchange, eliminating an inconsistency where normal chat succeeded but ephemeral side questions failed.

When using GitHub Copilot sessions, asking follow-up questions via /btw would fail with a model-not-supported error, even though the same session handled normal messages without issue. The problem was that /btw was sending the raw GitHub token directly to Copilot, while normal chat correctly exchanged it for a runtime token first. A one-line addition now routes /btw through the same provider runtime auth preparation that the main embedded runner uses, making side questions behave identically to regular chat in Copilot sessions. This narrows a behavioral gap that could have gone unnoticed until someone specifically used the /btw command.

View Original GitHub Description

Summary

Problem: /btw failed with 400 The requested model is not supported in sessions using github-copilot/gpt-5.4, even though normal chat in the same session worked.
Why it matters: Copilot-backed sessions had an inconsistent command path where normal turns worked but ephemeral side questions broke.
What changed: src/agents/btw.ts now applies provider runtime auth before sending the BTW side-question request, matching the main embedded runner path.
What did NOT change (scope boundary): no provider catalog changes, no gateway protocol changes, and no unrelated model-routing behavior changes.

Change Type (select all)

Scope (select all touched areas)

Linked Issue/PR

Closes #53925
Related #53925
This PR fixes a bug or regression

Root Cause (if applicable)

Root cause: the normal embedded runner path applies provider-owned runtime auth exchange in src/agents/pi-embedded-runner/run/auth-controller.ts, but /btw resolved auth directly in src/agents/btw.ts and skipped that step. For GitHub Copilot, that meant BTW used the raw GitHub token instead of exchanging it into the runtime Copilot token and entitlement-specific base URL provided by extensions/github-copilot/index.ts.
Missing detection / guardrail: there was no regression test covering /btw with a provider that requires runtime auth exchange.
Contributing context (if known): Copilot chat worked on the main path, which hid the bug until users exercised /btw specifically.

Regression Test Plan (if applicable)

Coverage level that should have caught this:
- Unit test
- Seam / integration test
- End-to-end test
- Existing coverage already sufficient
Target test or file: src/agents/btw.test.ts
Scenario the test should lock in: when /btw runs against github-copilot/gpt-5.4, it should apply provider runtime auth and stream using the exchanged runtime token/base URL.
Why this is the smallest reliable guardrail: the bug lives inside the BTW auth-preparation seam, so mocking that seam directly is the narrowest stable test.
Existing test that already covers this (if any): none
If no new test is added, why not: N/A

User-visible / Behavior Changes

/btw now works in GitHub Copilot sessions that require runtime auth exchange.

Diagram (if applicable)

Before:
/btw on github-copilot session -> raw GitHub token used directly -> Copilot rejects request

After:
/btw on github-copilot session -> runtime auth exchange -> Copilot runtime token/base URL -> side question succeeds

Security Impact (required)

New permissions/capabilities? (No)
Secrets/tokens handling changed? (Yes)
New/changed network calls? (No)
Command/tool execution surface changed? (No)
Data access scope changed? (No)
If any Yes, explain risk + mitigation: this change reuses the existing provider-owned runtime auth exchange already used by normal chat runs; it narrows behavior divergence rather than introducing a new credential path.

Repro + Verification

Environment

OS: macOS
Runtime/container: local dev gateway
Model/provider: github-copilot/gpt-5.4
Integration/channel (if any): Gateway chat.send on a dashboard session
Relevant config (redacted): loopback local gateway for verification; existing GitHub Copilot auth profile

Steps

Create or switch to a session using github-copilot/gpt-5.4.
Send a normal message.
Send /btw ... in the same session.

Expected

Both the normal message and /btw succeed.

Actual

Before the fix, /btw failed while the normal message succeeded.
After the fix, both succeed.

Evidence

Attach at least one:

Failing test/log before + passing after
Trace/log snippets
Screenshot/recording
Perf numbers (if relevant)

Human Verification (required)

What you personally verified (not just CI), and how:

Verified scenarios:
- Ran pnpm test src/agents/btw.test.ts
- Ran pnpm test src/auto-reply/reply/commands-btw.test.ts
- Ran pnpm build
- Started a local loopback gateway, created a fresh session pinned to github-copilot/gpt-5.4, confirmed a normal chat reply succeeded, then confirmed /btw returned a BTW side-result successfully instead of failing.
Edge cases checked:
- Copilot runtime auth test covers exchanged apiKey and baseUrl use in the BTW path.
What you did not verify:
- Other runtime-auth-exchange providers beyond GitHub Copilot.

Review Conversations

I replied to or resolved every bot review conversation I addressed in this PR.
I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

Backward compatible? (Yes)
Config/env changes? (No)
Migration needed? (No)
If yes, exact upgrade steps:

Risks and Mitigations

Risk: BTW now depends on provider runtime auth prep succeeding for providers that implement it.
- Mitigation: this matches the already-working main runner path and is covered by a focused regression test.