Fixes #72805

Summary

• Problem: GitHub Copilot's /models endpoint advertises gpt-5.5 and claude-opus-4.7-1m-internal, but extensions/github-copilot/models-defaults.ts:DEFAULT_MODEL_IDS is missing both. Users have to hand-edit ~/.openclaw/openclaw.json and run openclaw config validate to use them.
• Why it matters: Two newly-shipped Copilot models are unreachable out of the box. Additionally, even when a user adds the 1M Opus variant manually, buildCopilotModelDefinition resolves its contextWindow to the default 128_000, so the runtime would auto-compact long before the model actually runs out of context — silently capping a 1M-context session at ~13% of its real capacity.
• What changed: Added gpt-5.5 and claude-opus-4.7-1m-internal to DEFAULT_MODEL_IDS. Added a small helper resolveCopilotContextWindow(id) that returns 1_000_000 when the id ends with -1m or -1m-internal and 128_000 otherwise; buildCopilotModelDefinition now uses it instead of the bare DEFAULT_CONTEXT_WINDOW constant. Added 5 unit tests in extensions/github-copilot/models.test.ts.
• What did NOT change (scope boundary): Did not add the broader GPT-5.x family suggested in the issue (gpt-5.4, gpt-5.4-mini, gpt-5.3-codex, gpt-5.2-codex) — left for a follow-up so this PR matches the explicit "at minimum" ask in GitHub Copilot provider: add gpt-5.5 and claude-opus-4.7-1m-internal to default model list #72805. cost, reasoning, input modalities, maxTokens, the resolveCopilotTransportApi routing, and the existing getDefaultCopilotModelIds() mutable-copy contract are unchanged.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes GitHub Copilot provider: add gpt-5.5 and claude-opus-4.7-1m-internal to default model list #72805
• Related #
• This PR fixes a bug or regression

Root Cause

• Root cause: DEFAULT_MODEL_IDS is a hardcoded as const array in extensions/github-copilot/models-defaults.ts. It was last seeded against an older Copilot model availability snapshot and was never updated when Copilot rolled out gpt-5.5 and the 1M-context Opus variant. Separately, buildCopilotModelDefinition applies a single DEFAULT_CONTEXT_WINDOW = 128_000 to every model id, so even users who added the 1M model manually would get an incorrect context window.
• Missing detection / guardrail: there is no automated reconciliation between Copilot's /models endpoint and DEFAULT_MODEL_IDS. The list is updated by hand whenever a maintainer notices a new model has shipped. There was also no per-id context-window resolver, so -1m variants silently inherited the 128k default.
• Contributing context (if known): The file's existing comment already acknowledges the brittleness — "Copilot model ids vary by plan/org and can change. We keep this list intentionally broad; if a model isn't available Copilot will return an error and users can remove it from their config." — which made the static list acceptable for unavailable ids, but did not address the contextWindow correctness issue when a present-but-large-context id is added.

Regression Test Plan

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file: extensions/github-copilot/models.test.ts
• Scenario the test should lock in:
  1. getDefaultCopilotModelIds() includes "gpt-5.5".
  2. getDefaultCopilotModelIds() includes "claude-opus-4.7-1m-internal".
  3. buildCopilotModelDefinition("claude-opus-4.7-1m-internal").contextWindow === 1_000_000.
  4. buildCopilotModelDefinition("some-future-model-1m").contextWindow === 1_000_000 (covers the bare -1m suffix).
  5. buildCopilotModelDefinition("claude-opus-4.7").contextWindow === 128_000 (regression guard so non--1m ids stay on the default).
• Why this is the smallest reliable guardrail: DEFAULT_MODEL_IDS and buildCopilotModelDefinition are both pure helpers with no I/O — unit tests are deterministic and pinpoint regressions to either the array or the resolver. The existing test file already uses the same .toContain(...) style for the other Anthropic-family Copilot ids, so the new tests slot in next to their cousins.
• Existing test that already covers this (if any): None for gpt-5.5, claude-opus-4.7-1m-internal, or 1M context resolution. The closest existing coverage is the cluster of getDefaultCopilotModelIds().toContain(...) checks for the other Claude models, which doesn't constrain the new ids.
• If no new test is added, why not: N/A — 5 new tests added.

User-visible / Behavior Changes

• gpt-5.5 and claude-opus-4.7-1m-internal now appear in openclaw models list --provider github-copilot without manual config.
• agents.defaults.models entries that target either model id (or any future Copilot id ending in -1m / -1m-internal) get a contextWindow of 1_000_000 instead of 128_000, so auto-compaction triggers at the model's actual limit rather than ~13% of it.
• No defaults were removed or renamed. Existing user configs are untouched.

Diagram

Copilot model id resolution

Before:
buildCopilotModelDefinition("claude-opus-4.7-1m-internal")
  -> contextWindow: 128_000        (bug: misconfigured 1M model)

buildCopilotModelDefinition("gpt-4o")
  -> contextWindow: 128_000        (correct)

After:
buildCopilotModelDefinition("claude-opus-4.7-1m-internal")
  -> resolveCopilotContextWindow("claude-opus-4.7-1m-internal")
       endsWith "-1m-internal" -> true
  -> contextWindow: 1_000_000      (correct)

buildCopilotModelDefinition("gpt-4o")
  -> resolveCopilotContextWindow("gpt-4o")
       endsWith "-1m" / "-1m-internal" -> false
  -> contextWindow: 128_000        (unchanged)

Security Impact

• New permissions/capabilities? No
• Secrets/tokens handling changed? No
• New/changed network calls? No
• Command/tool execution surface changed? No
• Data access scope changed? No
• If any Yes, explain risk + mitigation: N/A

Repro + Verification

Environment

• OS: Linux 6.8.0-110-generic (Ubuntu)
• Runtime/container: Node 22+ via pnpm 10.33 (repo engines.node >=22.14.0)
• Model/provider: GitHub Copilot via OAuth (Copilot-Integration-Id: vscode-chat)
• Integration/channel (if any): N/A — provider plugin only
• Relevant config (redacted):

  // Before this PR, users had to add manually:
  {
    "agents": {
      "defaults": {
        "models": {
          "github-copilot/gpt-5.5": {},
          "github-copilot/claude-opus-4.7-1m-internal": { "params": { "thinking": "medium" } }
        }
      }
    }
  }

Steps

1. Authenticate the github-copilot provider with a Copilot subscription that exposes gpt-5.5 and claude-opus-4.7-1m-internal.
2. Run openclaw models list --provider github-copilot.
3. Inspect the resolved contextWindow for claude-opus-4.7-1m-internal (e.g. via openclaw models inspect github-copilot/claude-opus-4.7-1m-internal --json or by triggering a long session and observing where auto-compaction fires).

Expected

• Both gpt-5.5 and claude-opus-4.7-1m-internal appear in the listing without any user-side config edits.
• claude-opus-4.7-1m-internal reports contextWindow: 1000000.
• gpt-5.5 reports contextWindow: 128000.
• Models that aren't actually granted on the user's plan still surface the existing Copilot 404 Not Found / availability error from the backend, per the file's existing "intentionally broad" policy.

Actual (before fix)

• Neither model appears in openclaw models list --provider github-copilot.
• Adding claude-opus-4.7-1m-internal manually resolves it with contextWindow: 128000, causing premature auto-compaction at ~13% of the model's real capacity.

Evidence

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

$ pnpm test extensions/github-copilot/models.test.ts
 Test Files  1 passed (1)
      Tests  29 passed (29)   # 24 existing + 5 new (2 inclusion, 3 contextWindow)

pnpm check:changed is green: conflict markers, typecheck extensions, typecheck extension tests, lint extensions, runtime import cycles all pass.

Human Verification (required)

• Verified scenarios:
  • Targeted vitest run for extensions/github-copilot/models.test.ts (29/29 pass locally).
  • Full pnpm check:changed gate (extensions + extension-tests + lint + import-cycles, all green).
  • Re-read extensions/github-copilot/models.ts to confirm resolveCopilotTransportApi already classifies gpt-5.x ids correctly via existing test coverage at line 206 (["gpt-5.4-codex", "gpt-5.5-codex", "gpt-5.4-codex-mini", "gpt-5.3-codex"]), so adding gpt-5.5 to the default list does not need any transport-routing change.
• Edge cases checked:
  • Bare -1m suffix (covered by some-future-model-1m test) — future-proofs the resolver if Copilot ships a non-internal *-1m variant.
  • Non--1m ids still resolve to 128_000 — explicit regression guard so the resolver doesn't accidentally widen for unrelated ids.
  • getDefaultCopilotModelIds() mutable-copy invariant unchanged — existing test still passes after the array grew by 2.
• What you did not verify:
  • Live Copilot API call against https://api.githubcopilot.com/models with my own token. I do not have a Copilot subscription with claude-opus-4.7-1m-internal access, so I have not exercised the end-to-end path of "auth → list → spawn a session on the new model and watch a long context fill past 128k tokens." The issue reporter has the live evidence from https://api.githubcopilot.com/models, and the file's existing policy already documents that unavailable models surface the Copilot backend error.
  • Image-input handling for claude-opus-4.7-1m-internal. The default definition keeps input: ["text", "image"] since the resolver only changes contextWindow. If the 1M variant has different modality support, that is out of scope for this PR.

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.

(Both will be checked once review activity lands. Currently no bot review conversations on this PR.)

Compatibility / Migration

• Backward compatible? Yes
• Config/env changes? No
• Migration needed? No
• If yes, exact upgrade steps: N/A

Risks and Mitigations

• Risk: claude-opus-4.7-1m-internal is listed by Copilot as "Internal only" and may not be granted on every Copilot plan/org.
  • Mitigation: the existing file comment already covers this — "if a model isn't available Copilot will return an error and users can remove it from their config." This PR follows the same pattern that ships every other plan-restricted entry already in DEFAULT_MODEL_IDS (e.g. o1, o3-mini).
• Risk: a future Copilot model id could end with -1m without actually offering 1M context, which would set the wrong contextWindow.
  • Mitigation: the suffix is currently a strong signal (-1m / -1m-internal are explicit naming conventions for context-window variants). If Copilot ever ships a -1m id that means something different, the helper is one small place to update. Adding a generic naming-collision guardrail now would be speculative.
• Risk: contributors adding more -1m variants in the future might forget that the resolver depends on the suffix.
  • Mitigation: the resolveCopilotContextWindow helper is colocated with DEFAULT_MODEL_IDS and the suffix-test test cases, so any future addition will see both at once. No separate documentation needed.