PR #72829: Fix/copilot default models gpt 5 5 opus 1m

• Repository: openclaw/openclaw
• Author: iot2edge
• State: open | merged: False
• Link: https://github.com/openclaw/openclaw/pull/72829

Description (problem / solution / changelog)

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 #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 #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.

Changed files

• extensions/github-copilot/models-defaults.ts (modified, +4/-3)
• extensions/github-copilot/models.test.ts (modified, +41/-0)
• extensions/github-copilot/models.ts (modified, +8/-1)

PR #72850: fix(cli): clarify completion cache timeout message after openclaw update

• Repository: openclaw/openclaw
• Author: iot2edge
• State: closed | merged: True
• Link: https://github.com/openclaw/openclaw/pull/72850

Description (problem / solution / changelog)

Fixes #72842

Summary

• Problem: When openclaw update finishes, it spawns a child process to refresh the shell completion cache with a 30-second timeout. On slower environments (Debian/Docker, slow disk, large bundled-plugin trees) that child can exceed 30s and is killed. The user sees Completion cache update failed: Error: spawnSync /usr/bin/node ETIMEDOUT — Node's raw error string with no context.
• Why it matters: The reporter of #72842 saw this error twice in a row and explicitly asked "why does this happen?" The current message exposes a low-level Node error without telling the user (a) it's non-fatal, (b) what the cache does, or (c) how to recover. It looks alarming for what is actually a benign tab-completion staleness.
• What changed: In tryWriteCompletionCache (src/cli/update-cli/shared.ts), when the spawned child returns result.error, detect ETIMEDOUT and surface "timed out after 30s" instead of the raw Error: spawnSync /usr/bin/node ETIMEDOUT. Both the result.error and the non-zero result.status branches now also append a single-line manual-refresh hint: "Shell tab-completion may be stale; refresh manually with: openclaw completion --write-state". Added a regression test in src/cli/update-cli.test.ts that asserts the friendly text is logged and the raw Error: spawnSync string is not.
• What did NOT change (scope boundary): The 30-second timeout itself, the spawnSync call shape, the OPENCLAW_COMPLETION_SKIP_PLUGIN_COMMANDS env var, the silent return on error (still non-fatal), JSON-mode silence, and the duplicate-but-separate COMPLETION_CACHE_WRITE_TIMEOUT_MS constant in src/commands/doctor-completion.ts. Did not touch the underlying performance issue (fast plugin-load on cold start) — that is environment-specific and out of scope for a UX fix.

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 #72842
• Related #
• This PR fixes a bug or regression

Root Cause

• Root cause: After a successful openclaw update, update-command.ts calls tryWriteCompletionCache(postUpdateRoot, jsonMode). That function spawns node openclaw.mjs completion --write-state with a 30-second timeout. When the child takes longer than 30s (slow disk, bundled plugin tree cold-load, Docker overlayfs), Node's spawnSync kills the child and returns {error: SystemError(code: "ETIMEDOUT")}. The existing handler interpolates that error directly into the user-facing log: Completion cache update failed: ${String(result.error)}. The result string is Error: spawnSync /usr/bin/node ETIMEDOUT — accurate but unhelpful.
• Missing detection / guardrail: there was no test asserting the user-visible message text on the timeout/error path; the only existing coverage at src/cli/update-cli.test.ts:534 checked the spawn invocation arguments. So the message wording was never exercised.
• Contributing context (if known): the same 30-second timeout pattern is duplicated in src/commands/doctor-completion.ts:19-41, but that path uses result.status === 0 only and doesn't surface the error to the user, so the unhelpful message was Update-only.

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: src/cli/update-cli.test.ts (in the same describe block as "bounds completion cache refresh during update follow-up").
• Scenario the test should lock in:
  1. spawnSync returns {error: <ETIMEDOUT>} (mocked once).
  2. Logged warning includes "timed out after 30s".
  3. Logged warning includes the manual-refresh hint "openclaw completion --write-state".
  4. Logged warning does not include the raw "Error: spawnSync" string (regression guard against falling back to String(result.error)).
• Why this is the smallest reliable guardrail: tryWriteCompletionCache is a small async function with one external call (spawnSync). Mocking that single seam exercises every branch deterministically; no real subprocess is needed and the test runs in milliseconds.
• Existing test that already covers this (if any): None — bounds completion cache refresh during update follow-up only asserts the spawn invocation arguments, not the error path or message text.
• If no new test is added, why not: N/A — 1 new test added.

User-visible / Behavior Changes

• Before:

  Completion cache update failed: Error: spawnSync /usr/bin/node ETIMEDOUT

• After:

  Completion cache update failed: timed out after 30s. Shell tab-completion may be stale; refresh manually with: openclaw completion --write-state

• For non-timeout errors (rare), the message now also appends the manual-refresh hint. For non-zero exit status, same.
• JSON mode (--json) still suppresses the message entirely. Behavior for the success path is unchanged.
• The function is still non-fatal (returns silently after logging); openclaw update still reports overall success.

Diagram

openclaw update flow

Before:
[update succeeds]
  -> tryWriteCompletionCache spawns child (30s timeout)
  -> child times out (ETIMEDOUT)
  -> log: "Completion cache update failed: Error: spawnSync /usr/bin/node ETIMEDOUT"
  -> user: "is my install broken?"

After:
[update succeeds]
  -> tryWriteCompletionCache spawns child (30s timeout)
  -> child times out (ETIMEDOUT)
  -> log: "Completion cache update failed: timed out after 30s.
          Shell tab-completion may be stale; refresh manually with:
          openclaw completion --write-state"
  -> user knows it's harmless and how to recover

Security Impact

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

Repro + Verification

Environment

• OS: Debian (Docker), per the issue reporter
• Runtime/container: Node 22+, npm-installed openclaw global
• Model/provider: N/A — this is a CLI flow, not a model call
• Integration/channel (if any): N/A
• Relevant config (redacted): None

Steps

1. Install openclaw via npm install -g openclaw@latest in an environment where the bundled-plugin-tree cold-load takes >30s (e.g. Docker on slow disk).
2. Run openclaw update.
3. Observe the closing log line.

Expected

• Update reports overall success.
• Closing message: Completion cache update failed: timed out after 30s. Shell tab-completion may be stale; refresh manually with: openclaw completion --write-state.

Actual (before fix)

• Update reports overall success.
• Closing message: Completion cache update failed: Error: spawnSync /usr/bin/node ETIMEDOUT — opaque and alarming.

Evidence

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

$ pnpm test src/cli/update-cli.test.ts
 Test Files  1 passed (1)
      Tests  63 passed (63)   # 62 existing + 1 new for the friendly-timeout message

pnpm check:changed is green: conflict markers, typecheck, lint, runtime import cycles, plus the various core repo guard checks all pass.

Human Verification (required)

• Verified scenarios:
  • Targeted vitest run for src/cli/update-cli.test.ts (63/63 pass locally).
  • Full pnpm check:changed gate (all lanes green, including the additional core guards that fire when src/cli/** is touched).
  • Re-read the function before and after the change to confirm the success and JSON-mode paths are untouched.
• Edge cases checked:
  • result.error with code: "ETIMEDOUT" → friendly message with manual-refresh hint.
  • result.error without code: "ETIMEDOUT" → falls back to String(result.error), still appends manual-refresh hint.
  • Non-zero result.status (child ran but exited with error) → keeps original (${stderr}) detail and appends manual-refresh hint.
  • JSON mode (jsonMode: true) → no message logged in any branch.
  • Successful run (status: 0, no error) → no message logged (unchanged).
• What you did not verify:
  • Reproducing the original ETIMEDOUT on a real Debian/Docker install. The fix is purely user-facing message text and is fully covered by the unit test mock; reproducing the underlying performance issue requires a slow-disk environment that I do not have access to. The test asserts the exact branch the reporter hit.
  • The duplicate COMPLETION_CACHE_WRITE_TIMEOUT_MS in src/commands/doctor-completion.ts. That path doesn't surface a user-facing failure message and is therefore not affected by the bug; harmonizing the two constants would be a separate refactor and 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: a downstream tool that scrapes the existing Error: spawnSync /usr/bin/node ETIMEDOUT string will no longer match.
  • Mitigation: this is a warning log for human consumption, not part of any documented machine-readable surface. JSON mode (--json), which is what scriptable callers use, is unchanged and still emits no completion-cache message at all.
• Risk: the manual-refresh hint slightly lengthens the warning line on narrow terminals.
  • Mitigation: it's still a single line and warning-level (yellow). The added information directly answers the question the reporter asked. If a maintainer prefers a two-line layout, splitting on theme.warn(...) is a one-line follow-up.

Changed files

• src/cli/update-cli.test.ts (modified, +25/-0)
• src/cli/update-cli/shared.ts (modified, +17/-2)