Copilot long_context window reverts on restart: startup OAuth reconciliation deletes providers.github-copilot.modelContextWindows #7092

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   account-poolOAuth, credentials, Codex pool, quota, failover, plansOAuth, credentials, Codex pool, quota, failover, plans

   catalogModel catalog, slugs, visibility, routed entriesModel catalog, slugs, visibility, routed entries

   on Oct 14, 2026
2. geekxm commented on Oct 14, 2026

   

   geekxm

   on Oct 14, 2026

   More actions

   Confirming this reproduces on a different OAuth provider and a different OS, and adding
   one detail I think changes the severity: on this provider the operator's map is not merely
   removed — it is replaced by stale registry seeds that silently cap the advertised window.

   Environment

   • @bitkyc08/opencodex 2.84.0, macOS 27.0.1 (build 26A434), Apple Silicon arm64
   • Provider: xai (authMode: "oauth", OAuth/Grok-subscription lane) — not github-copilot
   • Model: xai/grok-composer-2.5-fast (in the registry roster XAI_MODELS, but with no live
     context metadata, so it has no seed and no discovery value)

   Exact code path (matches your diagnosis)

   src/oauth/index.ts:

   const OAUTH_RECONCILE_FIELDS: (keyof OcxProviderConfig)[] = [
     "models",
     "contextWindow",
     "modelContextWindows",   // line 1216  ← reconciled
     "defaultMaxOutputTokens",
     "modelMaxOutputTokens",  // line 1218
     ...
   ];
   
   const OAUTH_PRESERVE_WHEN_PRESET_UNSET: ReadonlySet<keyof OcxProviderConfig> = new Set([
     "defaultMaxOutputTokens",
     "modelMaxOutputTokens",  // lines 1257-1260  ← only these two are preserved
   ]);

   for (const field of OAUTH_RECONCILE_FIELDS) {
     if (JSON.stringify(provider[field]) === JSON.stringify(preset[field])) continue;
     if (preset[field] !== undefined) {
       provider[field] = cloneProviderField(preset[field]) as never;
     } else if (!OAUTH_PRESERVE_WHEN_PRESET_UNSET.has(field)) {
       delete provider[field];   // line 1302 — modelContextWindows lands here
     }
   }

   The xai preset defines models: XAI_MODELS but no modelContextWindows
   (src/providers/registry/entries-core.ts:320), so the delete branch fires.

   The asymmetry you observed is therefore structural, not Copilot-specific:
   modelMaxOutputTokens is in OAUTH_PRESERVE_WHEN_PRESET_UNSET and survives, while
   modelContextWindows is reconciled and has no preset value. I see exactly that split on xai:
   after repeated restarts modelMaxOutputTokens still held 17 operator entries while
   modelContextWindows held only the seed set.

   What makes it worse than "the field is removed"

   The field is not left absent — enrichProviderFromRegistry re-seeds it (fill-only, as the
   comment at lines 1233-1237 describes). So the operator's map is overwritten by seed values,
   and some of those seeds are larger than what the provider actually serves:

   stage	xai.modelContextWindows	/v1/models for grok-composer-2.5-fast
   after ocx config set providers.xai.modelContextWindows '{...}'	17 entries, both grok-composer-2.5-fast keys present at 200000	context_window: 200000
   after restart #1	back to the 9 seed entries; both added keys gone	still 200000 (router kept the loaded value)
   after restart #2	9 seed entries	context_window absent

   Because modelContextWindows caps rather than raises, the stale seed is usually harmless —
   but it is still wrong state the operator cannot correct durably. xai/grok-4.5 is seeded as
   500000 while live discovery reports 256000, so the saved row disagrees with what is served,
   and only the cap keeps the advertised value correct. On a model with neither a seed nor live
   metadata (grok-composer-2.5-fast) the field is simply gone, and every client sees no
   context_window at all.

   Reproduction on macOS (deterministic)

   1. Proxy running with the launchd service, xai on the OAuth lane.
   2. ocx config set providers.xai.modelContextWindows '{"grok-composer-2.5-fast":200000,"grok-composer-2.5-fast--fast":200000, ...}'
      (also reproducible via POST /api/providers {name:"xai", provider:{...}})
   3. ~/Library/Application Support/.../config.json (and ~/.opencodex/config.json) now shows
      the added keys; GET /v1/models reports context_window: 200000.
   4. Restart the proxy. The added keys are gone from config.json; GET /v1/models still reports
      200000 for that session.
   5. Restart again. GET /v1/models no longer reports context_window for that model.

   This reproduces even when the proxy is stopped before the edit, so it is the startup
   reconcile rather than the shutdown flush in #488.

   Suggested direction

   The file already contains the fix pattern for this exact hazard — lines 1233-1237 explain that
   requiresReasoningPlaceholderModels is deliberately kept out of OAUTH_RECONCILE_FIELDS
   because "the delete-when-preset-undefined branch would wipe an explicit user opt-out ([]) on
   every startup".

   modelContextWindows has the same property today: no OAuth preset seeds it, yet operators are
   expected to set it (the long-context workflow in your issue, and per-model fallbacks for models
   whose provider publishes no window). Either excluding it from OAUTH_RECONCILE_FIELDS, or
   adding it to OAUTH_PRESERVE_WHEN_PRESET_UNSET, would make it behave like
   modelMaxOutputTokens already does.

   Workaround in use

   A small script re-applies the operator's modelContextWindows entries and re-verifies
   /v1/models after each restart. Happy to test a patch if you want a second environment.