Agent-generated report: This issue was generated and filed by Fan's OpenClaw assistant from local runtime evidence on the user's behalf. Concrete user/channel/session identifiers and secrets were intentionally redacted.

Summary

On OpenClaw 2026.6.8 (844f405), channel/direct sessions using github-copilot/gpt-5.5 can still fail with 400 invalid_encrypted_content even though the installed build includes the merged replay fixes #84367, #90682, #92941, and #71448.

The affected session JSONL files still persist assistant blocks containing thinkingSignature, textSignature, and nested encrypted_content / encryptedContent. Later turns in the same channel/direct session can replay stale encrypted reasoning/signature material and the provider rejects the request before model output.

User-visible symptom: channel ingress is healthy, but the turn ends as LLM request failed / no deliverable assistant reply.

Severity / recurrence risk

This appears to be a high-severity, structurally recurring reliability bug, not a one-off corrupted local transcript. The current runtime can continue to persist provider-private Responses reasoning/signature material in long-lived channel/direct sessions. As those sessions age, the stored encrypted/signature payloads can become unverifiable for the current provider/auth/model/session context and then poison every later replay of the same session.

Why this is likely to recur without a code-level fix:

• The affected fields are still present in active session histories after the merged fixes listed below.
• Long-lived Discord/Telegram/Feishu conversations reuse the same session history for many turns, so stale replay material accumulates naturally.
• The failure happens before model output, producing user-visible LLM request failed / missing replies rather than a recoverable assistant response.
• Manual transcript cleanup can temporarily restore a session, but if new turns persist new thinkingSignature / textSignature / encrypted_content material, the same class of failure can reappear later.
• Gateway restart does not fix the root cause; it may simply reload and replay the persisted poisoned history again.

Suggested impact classification: P1 / user-facing reliability, with impact:message-loss and impact:session-state style consequences. This does not look like a security issue from the available evidence, but it can brick important long-running user/channel sessions until manual repair or a sanitized replay path is applied.

Environment

• OpenClaw: 2026.6.8 (844f405)
• Node: v22.22.2
• OS: Linux x64
• Provider/model: github-copilot/gpt-5.5
• Surfaces observed:
  • Discord direct
  • Telegram direct
  • Feishu direct
  • Some Discord channel/thread sessions

Evidence that the installed build includes prior fixes

Local installed OpenClaw:

OpenClaw 2026.6.8 (844f405)

GitHub compare checks showed local commit 844f405 is after these merged PRs:

• fix(agents): provenance-bound Codex reasoning replay #84367 fix(agents): provenance-bound Codex reasoning replay
  • merged 2026-05-20
  • local commit is ahead of the merge commit
• fix(openai): preserve opaque reasoning transcript fields #90682 fix(openai): preserve opaque reasoning transcript fields
  • merged 2026-06-14
  • local commit is ahead of the merge commit
• fix(openai): recover invalid reasoning signatures #92941 fix(openai): recover invalid reasoning signatures
  • merged 2026-06-14
  • local commit is ahead of the merge commit
• fix(github-copilot): preserve reasoning ids with encrypted_content #71448 fix(github-copilot): preserve reasoning ids with encrypted_content
  • merged 2026-04-25
  • local commit is ahead of the merge commit

Installed dist contains the expected fix-related code paths, including:

• isInvalidEncryptedContentError
• stripResponsesRequestEncryptedContent
• retry path log text: retrying without encrypted reasoning content
• replay provenance metadata helpers
• include: ["reasoning.encrypted_content"]
• transcript policy hook for dropReasoningFromHistory

Relevant excerpt from installed dist (sanitized):

function isInvalidEncryptedContentError(error) {
  if (record.code === "invalid_encrypted_content" || record.code === "thinking_signature_invalid") return true;
  return typeof record.message === "string" &&
    (record.message.includes("invalid_encrypted_content") || record.message.includes("thinking_signature_invalid"));
}

async function createResponsesStreamWithEncryptedContentRetry(params) {
  try {
    return await params.client.responses.create(params.request, params.requestOptions);
  } catch (error) {
    const retryRequest = stripResponsesRequestEncryptedContent(params.request);
    if (!isInvalidEncryptedContentError(error) || retryRequest === params.request) throw error;
    log.warn(`[responses] retrying without encrypted reasoning content provider=${params.model.provider} api=${params.model.api} model=${params.model.id}`);
    return await params.client.responses.create(retryRequest, params.requestOptions);
  }
}

Evidence from affected session files

Affected .jsonl session files still contain persisted replay-only fields:

thinkingSignature
textSignature
encrypted_content
encryptedContent

Observed counts in active session files included non-zero occurrences of those fields after the merged fixes were present. The exact session IDs and channel/user IDs are omitted here because they are private.

The raw provider error pattern is:

OpenAI API error (400): 400 The encrypted content ... could not be verified.
Reason: Encrypted content could not be decrypted or parsed.
code=invalid_encrypted_content

One failed assistant turn stored only:

{"type":"text","text":"[assistant turn failed before producing content]"}

with stopReason: "error" and an errorMessage containing the invalid_encrypted_content rejection.

Expected behavior

OpenClaw should not persist or replay stale provider-private encrypted reasoning/signature material in channel/direct session history, or should always recover by retrying with sanitized history before surfacing LLM request failed.

In particular, channel/direct embedded runtime paths should be covered, not just native/OpenAI Responses paths.

Actual behavior

A later turn in the same channel/direct session fails before model output with a user-visible LLM request failed, even though the channel provider and gateway ingress are healthy.

Manual mitigation by removing stale thinkingSignature / textSignature / encrypted_content fields from the local session transcript can restore the session, but new turns may persist new signature/encrypted fields again.

Suspected gap

The existing fixes appear to cover some Responses/Codex replay paths, but not all of:

• github-copilot/gpt-5.5
• OpenClaw main agent embedded runtime
• Discord/Telegram/Feishu direct/channel sessions
• persisted .jsonl history containing thinkingSignature / textSignature

Possible robust fixes:

1. Strip thinkingSignature / textSignature / encrypted_content at persistence time for Responses-family provider-private blocks, or mark them private/non-replayable.
2. Strip these fields at prompt/replay construction for all channel/direct embedded runtime paths.
3. On invalid_encrypted_content, retry with all reasoning/signature blocks removed, not just nested encrypted_content.
4. Add a session-repair migration or lazy repair for existing polluted .jsonl files.
5. Add regression tests for github-copilot/gpt-5.5 channel/direct session replay, not only native openai-chatgpt-responses paths.

Related issues / PRs

• Codex replay can silently fail Telegram turns with invalid_encrypted_content from mirrored thinking blocks #83836
• openai-chatgpt-responses native replay sends encrypted reasoning and breaks next turn with invalid_encrypted_content #90093
• GitHub Copilot Responses (gpt-5.x): multi-turn fails with 'encrypted content item_id did not match' #71333
• github-copilot/gpt-5.5: cross-turn reasoning fails — replayed encrypted_content rejected ("Encrypted content item_id did not match") #78867
• GPT-5.4 Responses API: encrypted_content item_id mismatch after model switch or compaction #70654
• [Bug]: microsoft-foundry reasoning models return 400 invalid_encrypted_content when continuing a thread #91033
• fix(agents): provenance-bound Codex reasoning replay #84367
• fix(openai): preserve opaque reasoning transcript fields #90682
• fix(openai): recover invalid reasoning signatures #92941
• fix(github-copilot): preserve reasoning ids with encrypted_content #71448
• fix(openai): drop encrypted reasoning from history for Responses-family APIs (fixes #90093) #92857 (closed unmerged; more aggressive history drop approach)
• fix(agents): drop unsafe Copilot reasoning replay IDs #85198 (closed unmerged; Copilot unsafe replay IDs)