[Bug]: GitHub Copilot Responses replay can send overlong reasoning item ids and fail with input[].id length error

AI-generated report. This issue was drafted by an AI assistant from local diagnostics; please treat details as a technical reproduction report and verify independently.

Bug type

Regression / provider compatibility bug

Summary

A Feishu group session using github-copilot/gpt-5.5 failed before generation with:

400 Invalid 'input[184].id': string too long. Expected a string with maximum length 64, but got a string with length 383 instead.

This looks related to #82749 / #82750, but it appears to be a different replay path. #82750 normalized overlong Copilot replay tool/function-call IDs. In this case the failing transcript contains replayed OpenAI Responses reasoning items stored in assistant thinkingSignature blocks with connection-bound id values around 408 characters. When convertResponsesMessages() reconstructs the outbound Responses input[], those reasoning items can still be emitted with the original overlong id, causing GitHub Copilot to reject the request schema before generation starts.

Steps to reproduce

1. Use an OpenClaw session on github-copilot/gpt-5.5 / openai-responses with reasoning enabled.
2. Accumulate assistant messages whose content[] includes thinking blocks with a JSON thinkingSignature representing a Responses reasoning item, e.g.:

{
  "type": "reasoning",
  "id": "<408-char connection-bound id>",
  "summary": []
}

1. Continue the same session later, so OpenClaw replays historical reasoning items through buildOpenAIResponsesParams().
2. Observe GitHub Copilot reject the outbound payload with an input[N].id maximum-length error.

Expected behavior

OpenClaw should never send GitHub Copilot Responses payload items with id longer than the provider's accepted limit. For replayed reasoning items, OpenClaw should either:

• drop the overlong reasoning.id,
• drop the whole replayed reasoning item for Copilot,
• disable reasoning-item replay for GitHub Copilot,
• or ensure the final Copilot payload sanitizer always removes/normalizes invalid reasoning IDs immediately before dispatch.

The session should continue instead of failing before generation.

Actual behavior

The provider rejects the request before generation:

OpenAI API error (400): 400 Invalid 'input[184].id': string too long. Expected a string with maximum length 64, but got a string with length 383 instead.

The channel dispatch then completes with no final reply:

dispatch complete (queuedFinal=false, replies=0)

Evidence from local diagnostics

Environment:

• OpenClaw package: 2026.5.18
• Provider/model: github-copilot/gpt-5.5
• API: openai-responses
• Integration/channel: Feishu group session
• The installed code includes the #82750-era tool-call normalization path, including normalizeSameModelToolCallIds and buildSameProviderCopilotResponsesItemId.

Relevant gateway log excerpt:

2026-05-21T00:46:10.515Z [feishu] received message ... in <redacted group> (group)
2026-05-21T00:46:11.086Z [feishu] dispatching to agent (session=<redacted feishu group session>)
2026-05-21T00:46:16.533Z [agent/embedded] embedded run agent end: runId=042175d2-19ea-4293-b007-ab1cf629e2c6 isError=true model=gpt-5.5 provider=github-copilot error=OpenAI API error (400): 400 Invalid 'input[184].id': string too long. Expected a string with maximum length 64, but got a string with length 383 instead.
2026-05-21T00:46:16.693Z [feishu] dispatch complete (queuedFinal=false, replies=0)

Session-file inspection found many long reasoning IDs:

long thinkingSignature ids: 31
(type: reasoning, id length: 408)

A local simulation of the installed convertResponsesMessages() behavior over that session produced:

converted items: 220
bad outbound id/call_id fields: 31
examples: (idx=183/190/etc, key=id, len=408, type=reasoning)

The simulated failing item class is type: "reasoning", not function_call.

Why this may not be fully covered by #82750

The installed OpenClaw code appears to include #82750's main fix:

• shouldNormalizeSameModelToolCallIds = model.provider === "github-copilot"
• same-provider Copilot tool-call item ID normalization via buildSameProviderCopilotResponsesItemId()
• tool-call ID mapping in transformTransportMessages()

However, buildOpenAIResponsesParams() still calls convertResponsesMessages() with:

replayReasoningItems: true,
replayResponsesItemIds: !isNativeCodexResponses

For github-copilot/gpt-5.5, isNativeCodexResponses is false, so replayResponsesItemIds remains true. convertResponsesMessages() then parses thinkingSignature JSON and pushes the reasoning item with its original id:

const reasoningItem = JSON.parse(block.thinkingSignature);
if (!shouldReplayResponsesItemIds) delete reasoningItem.id;
output.push(reasoningItem);

That means the tool-call normalization path from #82750 does not touch replayed reasoning item IDs.

There is also a Copilot wrapper sanitizer (sanitizeCopilotReplayResponseIds) that seems intended to remove invalid reasoning replay items, but this failure suggests either:

• it did not run on the actual final payload path,
• it ran before the reasoning items were added,
• it did not recognize the ID shape involved,
• or the provider-side failing input[184].id is produced through a path not covered by that sanitizer.

Impact

• User-facing channel sessions can silently fail to reply after a valid mention/message.
• The failure happens before generation, so no assistant response is produced.
• The session remains poisoned until history is compacted/reset or the replay behavior is fixed.

Workarounds

• Start a fresh session / clear or compact the affected transcript.
• Use a non-Responses provider fallback (e.g. Claude) for the affected session.
• Locally remove/rewrite historical reasoning thinkingSignature.id values from the session file.

Suggested fix

For GitHub Copilot Responses, make replayed reasoning items provider-valid at the request-builder seam. Possible options:

1. In convertResponsesMessages(), if model.provider === "github-copilot", delete reasoningItem.id when it is missing, over 64 chars, or otherwise not Copilot-valid.
2. Disable replayReasoningItems for github-copilot unless there is a confirmed benefit and valid ID handling.
3. Strengthen the final payload sanitizer so every input[] item with an id longer than 64 is either rewritten or dropped according to item type, and add a regression test that uses a replayed reasoning item with a 408-char id.

A focused regression test should build a github-copilot/gpt-5.5 Responses payload from a transcript containing a thinkingSignature JSON reasoning item with a 408-char id, then assert that every outbound input[].id is <= 64 (or that the reasoning item is omitted).