Reasoning effort can't be restored after selecting "off" on Claude Opus 4.7 (gateway rejects every non-off level with "use off")

[karkarl]

Summary

On github-copilot/claude-opus-4.7, once a session's reasoning effort (thinkingLevel) is set to off, there is no way to switch it back to any reasoning level. Every non-off value the UI sends (medium, max, …) is rejected by the gateway with ... is not supported for github-copilot/claude-opus-4.7 (use off). The model appeared to reason before off was selected, so this reads as a one-way trap.

This is independent of the WinUI chat-composer redesign — it reproduces on the latest tip of main and is a gateway/model-metadata + session-state issue, not a composer-layout issue. Filing separately so it isn't bundled into the composer PR.

Environment

• App: OpenClaw Tray (WinUI 3), latest main
• Gateway: setup-managed local WSL gateway, server version 2026.6.11
• Model: github-copilot/claude-opus-4.7 (provider github-copilot, api anthropic-messages)

Steps to reproduce

1. Configure a session on github-copilot/claude-opus-4.7.
2. Open the reasoning-effort picker and select off (e.g. while exploring the UI).
3. Try to switch the reasoning effort back to medium (or any other level).

Expected

The user can restore the model's previous/default reasoning behavior (either a working reasoning level, or a clearly-labeled "default"/"on" state).

Actual

The switch silently fails; the session stays on off. The gateway rejects the patch:

sessions.patch failed: thinkingLevel "medium" is not supported for github-copilot/claude-opus-4.7 (use off)
sessions.patch failed: thinkingLevel "max"    is not supported for github-copilot/claude-opus-4.7 (use off)

There is no exposed path back to the model's default reasoning state — the only gateway-accepted explicit value is off.

Evidence: contradictory model metadata

models.list reports this model as non-reasoning yet simultaneously advertises a full effort list:

{
  "id": "claude-opus-4.7",
  "name": "Claude Opus 4.7",
  "provider": "github-copilot",
  "api": "anthropic-messages",
  "contextWindow": 128000,
  "reasoning": false,
  "compat": { "supportedReasoningEfforts": ["low","medium","high","xhigh","max"] },
  "available": true
}

So reasoning: false and compat.supportedReasoningEfforts: [low,medium,high,xhigh,max] disagree, and the sessions.patch validator only accepts off. A UI cannot trust the advertised effort list to decide what is selectable.

Analysis / open questions

Two candidate root causes (need gateway-side confirmation):

1. One-way "off" trap. The model's default (unset thinkingLevel) may be a working reasoning state, and setting an explicit off leaves no way to return to that default — there's no default/unset/on value the UI can send, and off is the only accepted explicit value. If so, the gateway and/or UI needs a way to clear/restore the default reasoning state.
2. Stale/incorrect reasoning metadata for Copilot-hosted Anthropic models — if Opus 4.7 truly supports reasoning through Copilot, reasoning: false (and the patch validator's use off) is wrong and should be corrected so real efforts are accepted.

Impact

• Users can permanently (per session) lose reasoning on a model after a single stray toggle, with no visible recovery path.
• The contradictory reasoning vs supportedReasoningEfforts metadata makes it impossible for the client to present an accurate, gate-correct reasoning picker.

Notes for the client-side follow-up

• A partial client-side mitigation was prototyped (gate the reasoning picker on the reasoning flag and disable unsupported efforts instead of letting them silently fail). That improves honesty but does not solve the core problem — restoring reasoning after off — because the gateway still accepts only off for this model. The real fix depends on resolving the open questions above (a "default/restore" path and/or correct metadata).

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed July 13, 2026, 4:39 PM ET / 20:39 UTC.

Summary
Keep open. The report provides a specific current-main reproduction and gateway rejection transcript for a real one-way session-state trap; neither current target-repository evidence nor the latest release establishes a fix, and no canonical same-repository item was found.

Likely related people

• shanselman — likely target-side routing owner for native chat and gateway integration (medium confidence).
• christineyan4 — recent contributor around native chat UI behavior (medium confidence).

Reproducibility: yes. Select off for a github-copilot/claude-opus-4.7 session on current main, then select medium or max; the supplied gateway transcript shows both patches rejected while the session remains off.

Next step
Confirm the gateway’s intended Copilot reasoning contract and ownership before assigning a target-side fix; implementing either interpretation without that decision could preserve the trap or expose invalid options.

Maintainer decision needed

• Question: For github-copilot/claude-opus-4.7, should the gateway accept the advertised explicit reasoning efforts, or should clients restore reasoning only by clearing the session override while treating the model as non-reasoning?
• Rationale: The client cannot safely infer the intended provider contract because reasoning, supportedReasoningEfforts, observed default behavior, and patch validation disagree.
• Likely owner: shanselman — This person is the strongest available target-side owner to coordinate the native client behavior with the gateway’s session/model contract.
• Options:
  • Support clear/default state (recommended): Make clearing thinkingLevel a supported session operation, expose Default/Restore in clients, and advertise only explicit efforts the provider actually accepts.
  • Enable advertised efforts: Correct the model metadata and validator so every advertised Copilot Opus 4.7 effort is accepted and tested end to end.
  • Treat model as off-only: Remove the contradictory effort list and hide the picker, accepting that reasoning cannot be explicitly controlled for this provider/model.

Review details

Best possible solution:

Define one gateway contract in which model metadata, accepted patch values, and clearing an override agree; then expose a visible Default/Restore option in WinUI that clears the explicit level and surfaces any gateway rejection instead of silently retaining off.

Do we have a high-confidence way to reproduce the issue?

Yes. Select off for a github-copilot/claude-opus-4.7 session on current main, then select medium or max; the supplied gateway transcript shows both patches rejected while the session remains off.

Is this the best way to solve the issue?

Unclear until the gateway contract is confirmed. Capability-gating the picker is a useful mitigation, but the complete fix must also provide a supported way to clear the explicit session override or accept the advertised levels.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The gateway’s intended contract for Copilot-hosted Anthropic reasoning remains unconfirmed: either the model metadata is wrong or the session API must expose a supported clear/default operation.
• A client-only capability gate would prevent invalid selections but would leave existing sessions stuck on explicit off unless it can send a gateway-supported unset/default patch.
• Changing accepted effort levels without provider-specific live proof could expose controls that the Copilot backend still rejects.

Codex review notes: model internal, reasoning high; reviewed against 77c42440376e.

Label changes

Label changes:

• add P2: The bug deterministically traps a session’s reasoning state for one provider/model path, but does not make the overall runtime unusable.
• add impact:session-state: An explicit per-session reasoning setting cannot be restored to its prior/default state.
• add impact:auth-provider: The failure is driven by provider/model capability metadata and gateway validation for GitHub Copilot.
• add impact:ux-friction: The picker permits a one-way selection and silently leaves users without an exposed recovery path.
• add issue-rating: 🦀 challenger crab: Current issue advisory state selects this label.
• add clawsweeper:current-main-repro: Current issue advisory state selects this label.
• add clawsweeper:no-new-fix-pr: Current issue advisory state selects this label.
• add clawsweeper:needs-maintainer-review: Current issue advisory state selects this label.
• add clawsweeper:needs-product-decision: Current issue advisory state selects this label.

Label justifications:

• P2: The bug deterministically traps a session’s reasoning state for one provider/model path, but does not make the overall runtime unusable.
• impact:session-state: An explicit per-session reasoning setting cannot be restored to its prior/default state.
• impact:auth-provider: The failure is driven by provider/model capability metadata and gateway validation for GitHub Copilot.
• impact:ux-friction: The picker permits a one-way selection and silently leaves users without an exposed recovery path.

Evidence reviewed

Acceptance criteria:

• ./build.ps1
• dotnet test ./tests/OpenClaw.Shared.Tests/OpenClaw.Shared.Tests.csproj --no-restore
• dotnet test ./tests/OpenClaw.Tray.Tests/OpenClaw.Tray.Tests.csproj --no-restore
• Capture a current-head WinUI recording showing off followed by successful Default/Restore behavior
• Capture redacted live gateway models.list and sessions.patch request/response output for github-copilot/claude-opus-4.7

What I checked:

• Current-main reproduction: The reporter gives deterministic steps on target main with gateway 2026.6.11 and captures sessions.patch rejecting both medium and max while requiring off; this is concrete evidence that the session cannot return through the exposed picker. (77c42440376e)
• Contradictory gateway metadata: The captured models.list entry simultaneously reports reasoning: false and advertises five supported reasoning efforts, so the client lacks a consistent capability contract for constructing valid session patches.
• Existing session contract: OpenClaw’s session documentation describes /think without a level as clearing the per-session override, supporting an established default/unset state rather than making explicit off irreversible. citeturn114372523789680.
• Target product surface: The target repository describes native chat as supporting per-session controls and relies on an OpenClaw gateway for session behavior, so both the WinUI picker and gateway contract are relevant to the reported failure. citeturn583322915235680. (README.md:75, 77c42440376e)
• Release status: The report reproduces on current main 77c42440376e2b8cd503290bb2bfc7ac816bab63, which is newer than latest release v0.6.12 at 4166e0fd63f80a9ac330e6e4d9b89066c0e1ac50; there is no source/history proof supporting an implemented-on-main or shipped-fix close. (77c42440376e)

Likely related people:

• shanselman: The repository history and project surface associate this person with the Windows companion app and its native chat/gateway integration, making them the strongest target-side routing candidate for a cross-boundary session contract decision. (role: feature owner; confidence: medium; files: src/OpenClaw.Tray.WinUI/Chat, src/OpenClaw.Shared/Sessions)
• christineyan4: Recent merged work is associated with native chat UI behavior, so this person is a useful reviewer for picker-state presentation and client-side recovery behavior. (role: recent area contributor; confidence: medium; files: src/OpenClaw.Tray.WinUI/Chat)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

[calebeden]

This seems like it might be an issue with the gateway, not necessarily the Windows Companion App. In the web UI, I am able to set the "reasoning level" to high and then query with /status and see that it is preserved as "Think: high Reasoning: on" even though the UI refreshes to show "Off" in the input area. So the same bug appears to be showing up there.