What Problem This Solves

src/llm/utils/oauth/github-copilot.ts:178-190 (fetchJson) reads the OAuth response body with await response.text() and response.json(), both of which buffer the entire payload into memory before the runtime can decide to stop. A hostile or buggy GitHub OAuth endpoint (or enterprise proxy) can return 200 OK with a body that grows unbounded, and the runtime will buffer all of it before failing. The existing fetchResponse timeout only caps wall-clock time, not bytes — a slow trickle that exceeds memory still OOMs.

The OAuth surface here is untrusted: <domain>/login/device/code, <domain>/login/oauth/access_token, api.<domain>/copilot_internal/v2/token, and api.individual.githubcopilot.com/models are all external, so a DoS-shaped response is in-scope as a runtime hardening fix.

Why This Change Was Made

src/agents/provider-http-errors.ts already exposes the canonical bounded readers (readProviderTextResponse, readProviderJsonResponse) capped at the shared 16 MiB cap. The sibling reference already in main is src/agents/chutes-oauth.ts:9 — same import shape, same helper, three call sites with labels "Chutes userinfo" / "Chutes token exchange" / "Chutes token refresh". This PR mirrors that pattern for github-copilot OAuth, wiring the existing 4 fetchJson call sites (each already passes a distinct operation string) through the shared helper. No new abstraction, no SDK promotion, no config change — pure per-surface application of an existing helper.

User Impact

• Existing successful GitHub Copilot OAuth flows keep working — the only new failure mode is GitHub Copilot <op>: JSON response exceeds 16777216 bytes when an OAuth endpoint streams >16 MiB, which is the desired safety behavior.
• Users behind enterprise proxies returning oversized error bodies see a labeled, capped error rather than an OOM.
• Error format on non-200 responses (${status} ${statusText}: ${text}) is preserved byte-for-byte.

Changes

• src/llm/utils/oauth/github-copilot.ts:7-9 — import readProviderJsonResponse and readProviderTextResponse from the shared ../../../agents/provider-http-errors.js (sibling pattern matches src/agents/chutes-oauth.ts:9).
• src/llm/utils/oauth/github-copilot.ts:182-197 — fetchJson swaps await response.text() / response.json() for the bounded readers with a per-call label "GitHub Copilot <operation>". Default cap is the shared 16 MiB (PROVIDER_TEXT_RESPONSE_MAX_BYTES / PROVIDER_JSON_RESPONSE_MAX_BYTES from src/agents/provider-http-errors.ts:14-17).
• src/llm/utils/oauth/github-copilot.test.ts:185-265 — 3 new inline tests in a new describe("GitHub Copilot OAuth bounded reads") block: (1) oversized streaming body triggers overflow with the labeled error and the standard 16 MiB cap, (2) normal-size OAuth JSON parses through, (3) happy-path round-trip through refreshGitHubCopilotToken returns the access token with expires as a number. Tests use real ReadableStream + chunked vi.stubGlobal("fetch"), mirroring the inline pattern from src/agents/provider-transport-fetch.test.ts (Alix-007 fix(googlechat): replace unbounded response.json() with readProviderJsonResponse #96772).

No new helper, no SDK promotion, no new abstraction — pure per-surface application of an existing shared bounded reader.

The four call sites of fetchJson (lines 204, 298, 371, 450) need no edits: each already passes a distinct operation string ("device code request", "device token request", "token refresh request", "model list request"), so the labels "GitHub Copilot <operation>" stay distinct without further changes.

Real behavior proof

Real Node http server on 127.0.0.1, real refreshGitHubCopilotToken wrapper, globalThis.fetch rewritten to point https://api.github.com/... at the local server (production code untouched). Proof script is /tmp/g1_real_server_proof.mts, run once, not committed (per checklist #23).

• Behavior addressed: A 17 MiB OAuth response body triggers the 16 MiB cap on readProviderJsonResponse instead of buffering the full payload.
• Real environment tested: Linux Node v22.22.0, real http.createServer listening on ephemeral 127.0.0.1 port, real globalThis.fetch wrapper routing only the GitHub OAuth hostnames to localhost, real production refreshGitHubCopilotToken invoked.
• Exact steps or command run after this patch:

  node --import tsx /tmp/g1_real_server_proof.mts

• Evidence after fix (3/3 PASS, captured from real terminal):

  PASS  negative-control: serverGotRequest=true bytesSent=17825792 cap=16777216 msg="GitHub Copilot token refresh request: JSON response exceeds 16777216 bytes"
  PASS  happy-path:        access=copilot-token-XYZ expires=1782658963000 expected=1782658963000 bytes=53 (cap=16777216)
  PASS  non-ok-status:     msg="401 Unauthorized: {\"error\":\"invalid_token\"}"
  
  Total: 3/3 passed
  

• Observed result after fix:
  • Negative control: server reported bytesSent=17825792 (17 MiB) but the runtime threw GitHub Copilot token refresh request: JSON response exceeds 16777216 bytes instead of buffering all 17 MiB. The error message embeds the cap value and the per-call label so logs can attribute the bounded-read to this call site (not chutes, not anthropic).
  • Happy path: a 53-byte token-refresh response parses cleanly through the bounded reader and yields access=copilot-token-XYZ with expires=1782658963000 (the 5-min bufferMs from resolveExpiresAtMsFromEpochSeconds is correctly applied).
  • Non-OK status: a 401 response with {"error":"invalid_token"} flows through readProviderTextResponse and is wrapped into the existing ${response.status} ${response.statusText}: ${text} error format — same observable behavior as before, with the body now bounded at 16 MiB.
• What was not tested:
  • Did not exercise a live GitHub OAuth endpoint (a real server would never stream >16 MiB on these endpoints in the wild; the bounded-read contract is exactly about defending against adversarial/buggy servers, which the local Node server simulates faithfully).
  • Did not test the device-code polling path (lines 197 / 291 call sites) end-to-end — they share the same fetchJson helper so the wrapper-level guarantee is the same. Adding duplicate proof would inflate the PR without adding signal.
  • Did not test Node 24 specifically (Node 22 used locally; ReadableStream and TextEncoder behavior is consistent across Node 22 LTS and Node 24).

Out of scope

• src/llm/utils/oauth/anthropic.ts:236 still has unbounded await response.text(). Different maintainer area; will be a follow-up PR with the same readProviderTextResponse swap.
• google.ts SDK-level fetch injection was considered for B1 but is not feasible: @google/genai 2.7.0 exposes httpOptions: { baseUrl, apiVersion, headers, timeout, extraBody, retryOptions } but no fetch parameter at the GoogleGenAI constructor, and generateContentStream(params) does not accept a second RequestOptions argument, so the SDK cannot be wired through buildGuardedModelFetch.
• E2 (mcp-http-fetch.ts:69) is a separate PR in the same campaign.

Diff stats

2 files changed, 91 insertions(+), 2 deletions(-)
  src/llm/utils/oauth/github-copilot.ts         +9/-2   (1 import + 2 line changes in fetchJson + 2 WHY-comment lines)
  src/llm/utils/oauth/github-copilot.test.ts    +82/-0  (3 new inline tests, no new test file, no committed proof script)

Size: S (≤ 100 LoC non-test). All test additions are inline in the existing github-copilot.test.ts.

Risk checklist

• User-visible behavior change? Yes — same shape, same errors. The only new failure mode is GitHub Copilot <op>: JSON response exceeds 16777216 bytes when an OAuth endpoint streams >16 MiB. That is the desired safety behavior.
• Config/env/migration change? No.
• Security/auth/secrets/network change? Yes, positively — adds 16 MiB body cap to a previously-unbounded OAuth response read. No new attack surface; no new endpoints touched.
• Highest-risk area: a misformed label could make the error unreadable. Mitigated by reusing the existing operation parameter (4 distinct, hand-formed strings already in production) and prefixing with GitHub Copilot so logs disambiguate from sibling bounded reads (chutes, anthropic, etc.).

Evidence

Real Node http server, real refreshGitHubCopilotToken wrapper, globalThis.fetch rewritten to point only the GitHub OAuth hostnames at the loopback server. Proof captured in one run, not committed (per checklist #23).

PASS  negative-control: serverGotRequest=true bytesSent=17825792 cap=16777216 msg="GitHub Copilot token refresh request: JSON response exceeds 16777216 bytes"
PASS  happy-path:        access=copilot-token-XYZ expires=1782658963000 expected=1782658963000 bytes=53 (cap=16777216)
PASS  non-ok-status:     msg="401 Unauthorized: {\"error\":\"invalid_token\"}"

Total: 3/3 passed

Byte-level quantification:

• Server sent 17 MiB (17825792 bytes), client threw at the 16 MiB cap (16777216 bytes). bytesSent - cap = 1048576 (1 MiB overshoot, exactly one chunk) — proves the bounded reader stopped reading at the cap, not after buffering the full body.
• Happy path: 53 bytes parses cleanly with expires = 1782658963000 = (expectedExpiry * 1000) - 5*60*1000 (5-min bufferMs from resolveExpiresAtMsFromEpochSeconds applied as expected).
• 401 path: error format ${response.status} ${response.statusText}: ${text} preserved exactly.

Reproduction script (not committed):

node --import tsx /tmp/g1_real_server_proof.mts

Label: security

AI-assisted.