Summary

Using github-copilot/gpt-5.5 (registered with api: "openai-responses" against https://api.enterprise.githubcopilot.com) breaks across turns because reasoning encrypted_content from the previous turn is replayed and rejected by the upstream:

400 The encrypted content for item rs_<...> could not be verified.
Reason: Encrypted content item_id did not match the target item id.

The first turn succeeds (model returns thinking + tool call). On the next turn, OpenClaw replays the prior assistant message including the thinkingSignature JSON (which holds copilot's encrypted_content + id) and copilot rejects it. Every subsequent request to that session fails with the same shape (different rs_* id each turn). Setting reasoning: false on the model entry works around it.

Repro

1. Configure openclaw.json:

"models": {
  "providers": {
    "github-copilot": {
      "baseUrl": "https://api.enterprise.githubcopilot.com",
      "headers": {
        "Editor-Version": "vscode/1.96.2",
        "Copilot-Integration-Id": "vscode-chat",
        "User-Agent": "GitHubCopilotChat/0.26.7"
      },
      "models": [{
        "id": "gpt-5.5",
        "api": "openai-responses",
        "reasoning": true,
        "input": ["text", "image"],
        "contextWindow": 272000,
        "maxTokens": 128000,
        "compat": { "supportsReasoningEffort": true, "supportsUsageInStreaming": true }
      }]
    }
  }
}

2. Set an agent's model to github-copilot/gpt-5.5.
3. Send turn 1 — succeeds (assistant produces thinking + tool call).
4. Send turn 2 — fails with 400 The encrypted content for item rs_<id> could not be verified.
5. All subsequent turns fail (different rs_* id each time, but same error class).

Trajectory evidence

The trajectory messagesSnapshot for turn 2 includes the prior assistant message with:

{
  "type": "thinking",
  "thinking": "...",
  "thinkingSignature": "{\"encrypted_content\":\"kf0lc1GTQk6...\",\"id\":\"R9G8DlyXvlz...\",\"summary\":[...],\"type\":\"reasoning\"}"
}

This encrypted_content + id pair is being re-sent to copilot's /responses endpoint and fails verification.

Suspected cause

OpenClaw's openai-responses path replays full conversation history including reasoning items each turn. GPT-5 reasoning over /responses is designed to be referenced via previous_response_id rather than re-sent verbatim — or its encrypted state has a binding/TTL that doesn't survive a re-send. Either way, replaying encrypted_content from a prior turn is what trips upstream validation.

For comparison: github-copilot's claude-opus-4.6 works fine on the same setup, and github-copilot/gpt-5.5 works fine if reasoning: false.

Other observation (probably related)

/clear sent into a session via sessions_send did not actually purge the transcript — subsequent turns still re-attached the broken reasoning items. I had to physically truncate agents/<id>/sessions/<sessionId>.jsonl to recover. (Possibly /clear only clears in-context window but not the persisted transcript that's read on next turn.)

Workaround

Set reasoning: false on the github-copilot/gpt-5.5 model entry. Single-turn reasoning still works inside one round; cross-turn is what blows up.

Environment

• OpenClaw 2026.4.22 (00bd2cf), package version 2026.3.8
• macOS, node v22
• Provider: github-copilot via https://api.enterprise.githubcopilot.com (Editor-Version: vscode/1.96.2, Copilot-Integration-Id: vscode-chat)
• Model: gpt-5.5, api: openai-responses