Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix Slack continuation can lose prior plan context and Responses continuation fails with thinking_signature_invalid [1 pull requests, 1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#84002•Fetched 2026-05-20 03:45:23
View on GitHub
Comments
1
Participants
2
Timeline
9
Reactions
1
Author
tianxiaochannel-oss88tianxiaochannel-oss88
Participants
clawsweeper[bot]clawsweeper[bot]tianxiaochannel-oss88tianxiaochannel-oss88
Timeline (top)
labeled ×7commented ×1cross-referenced ×1

I observed two continuation-related failures in a local OpenClaw Slack workflow. They may be separate bugs, but they appeared in the same day while trying to continue a prior plan from Slack.

  1. A follow-up intent such as "OK, follow what you just said" was routed into an empty/main session with no prior assistant plan available, so the agent could not recover the referenced plan.
  2. Other Slack thread continuations failed before the assistant could produce content with thinking_signature_invalid / encrypted reasoning content verification errors from the Responses API path.

No secrets, Slack tokens, or full session transcripts are included below.

Error Message

  • If recovery is impossible, OpenClaw should surface a clear recovery error instead of letting the agent tool-loop through empty session lookups. In a Slack thread continuation, subsequent turns failed before producing assistant content. Sanitized error evidence: finalStatus=error
  • The user should receive a visible error/recovery notice instead of an apparent silent stall.

Root Cause

For Slack-based agent workflows, continuation phrases are common. Losing the previous plan or failing on an invalid encrypted reasoning item makes the agent appear to forget, even when the memory framework and long-term memory files are not the root cause.

Fix Action

Fixed

PR fix notes

PR #84267: fix(agents): recover invalid OpenAI Responses reasoning replay

Description (problem / solution / changelog)

Fixes the OpenAI Responses half of #84002.

This intentionally does not change Slack main/thread session routing. The issue combines two continuation failures; this PR addresses the deterministic Responses replay failure where preserved encrypted reasoning can be rejected with thinking_signature_invalid.

Root cause

OpenAI Responses can reject a replayed encrypted reasoning item when the stored rs_* content is no longer verifiable. Current history cleanup only drops replayable OpenAI reasoning when the model snapshot changes or when the reasoning block is orphaned, so a same-provider/same-model continuation can replay the stale encrypted reasoning again.

That error was also classified as a generic schema/format rejection, so terminal failures surfaced as "provider rejected the request schema" instead of a replay-state recovery error.

What changed

  • Classify thinking_signature_invalid and encrypted reasoning verification/decryption failures as replay-invalid.
  • Wrap OpenAI Responses stream calls with a one-shot recovery path:
    • if the request fails before any streamed chunk, or the current Responses transport emits a pre-start assistant error event/result with invalid encrypted reasoning, drop replayable OpenAI reasoning blocks
    • downgrade paired call|fc tool call ids after dropping reasoning
    • retry the same model call once
    • keep dropping replayable reasoning for later calls in the same session wrapper after recovery is activated
  • Do not retry if any stream chunk was already yielded, to avoid duplicate visible output/events.

User impact

A Slack or channel continuation that hits stale OpenAI Responses encrypted reasoning should get one clean retry instead of ending the turn with no visible assistant content. If the retry still fails, the user-facing error now points to invalid session/replay state instead of a generic schema rejection.

Real behavior proof

Behavior or issue addressed: OpenAI Responses continuation recovery for thinking_signature_invalid / invalid encrypted reasoning replay.

Real environment tested: Local OpenClaw checkout on this PR branch (edc7ccba2a0ab7a3f972362b5ee74753ff0fb302) on macOS with Node v24.15.0. The committed proof harness uses the real OpenAI SDK HTTP transport and OpenClaw's current createOpenAIResponsesTransportStreamFn() plus wrapOpenAIResponsesStreamWithReplayRecovery() against a loopback /v1/responses endpoint. It does not mock the OpenAI SDK; the loopback endpoint returns provider-shaped HTTP 400 and SSE responses so reviewers can inspect the request/retry payload transition.

Exact steps or command run after this patch:

node --import tsx scripts/proofs/openai-responses-replay-recovery.ts

Evidence after fix:

[openai-transport] [responses] error provider=openai api=openai-responses model=gpt-5.4 name=Error status=400 code=thinking_signature_invalid type=invalid_request_error causeName=undefined causeCode=undefined message=400 The encrypted content for item rs_real_transport_proof could not be verified. Reason: Encrypted content could not be decrypted or parsed.
[agent/embedded] [session-recovery] OpenAI Responses reasoning replay rejected; retrying once without replayable reasoning: sessionId=real-http-transport-proof-session
OpenAI Responses replay recovery proof: PASS
Runtime path: real OpenAI SDK HTTP transport against loopback /v1/responses
Mocking: no vi.mock/openai SDK mock; loopback server returns provider-shaped HTTP/SSE
Requests observed: 2
Request paths: /v1/responses, /v1/responses
First response: HTTP 400 thinking_signature_invalid
First request input types: reasoning, message
Retry request input types: message
Retry dropped replayed reasoning: true
Retry preserved replayed message: true
Recovered assistant text: recovered via real http transport
Final stopReason: stop

Observed result after fix: The first real SDK HTTP request contains replayed reasoning and receives a provider-shaped thinking_signature_invalid 400. The wrapper retries once. The second real SDK HTTP request drops replayed reasoning, preserves the replayed visible message, consumes the SSE response, and returns assistant text with stopReason: stop.

Committed inspectable proof: scripts/proofs/openai-responses-replay-recovery.ts is the manual proof harness. src/agents/pi-embedded-runner/openai-responses-transport-replay-recovery.test.ts remains the regression test that locks in the mocked-SDK transport error-event path.

What was not tested: Live Slack and live OpenAI Responses were not used. Slack session routing from #84002 is intentionally out of scope for this PR.

Exact steps or command run after this patch

node --import tsx scripts/proofs/openai-responses-replay-recovery.ts
./node_modules/.bin/oxlint --tsconfig config/tsconfig/oxlint.scripts.json scripts/proofs/openai-responses-replay-recovery.ts
node scripts/run-vitest.mjs src/agents/pi-embedded-runner/openai-responses-transport-replay-recovery.test.ts
node scripts/run-vitest.mjs src/agents/pi-embedded-runner/thinking.test.ts
node scripts/run-vitest.mjs src/agents/pi-embedded-helpers.formatassistanterrortext.test.ts
node scripts/run-tsgo.mjs -p tsconfig.core.json --incremental --tsBuildInfoFile .artifacts/tsgo-cache/core.tsbuildinfo
git diff --check

Validation

openai-responses-replay-recovery.ts proof harness: PASS
script oxlint: 0 warnings, 0 errors
openai-responses-transport-replay-recovery.test.ts: 2 test files, 2 tests passed
thinking.test.ts: 33 passed
pi-embedded-helpers.formatassistanterrortext.test.ts: 64 passed
tsgo core: passed
git diff --check: passed

Changed files

  • scripts/proofs/openai-responses-replay-recovery.ts (added, +275/-0)
  • src/agents/pi-embedded-helpers.formatassistanterrortext.test.ts (modified, +9/-0)
  • src/agents/pi-embedded-helpers/errors.ts (modified, +7/-1)
  • src/agents/pi-embedded-runner/openai-responses-transport-replay-recovery.test.ts (added, +160/-0)
  • src/agents/pi-embedded-runner/run/attempt.ts (modified, +9/-1)
  • src/agents/pi-embedded-runner/thinking.test.ts (modified, +276/-0)
  • src/agents/pi-embedded-runner/thinking.ts (modified, +170/-1)

Code Example

OK, follow what you just said.

---

sessionKey=agent:main:main

---

sessions_history => messages=[]
sessions_list => count=0

---

status=400
code=thinking_signature_invalid
type=invalid_request_error
message="The encrypted content for item rs_... could not be verified. Reason: Encrypted content could not be decrypted or parsed."
providerRuntimeFailureKind=schema
fallbackConfigured=false
fallbackStepFinalOutcome=chain_exhausted

---

finalStatus=error
terminalError=non_deliverable_terminal_turn
aborted=false
timedOut=false
idleTimedOut=false
didSendViaMessagingTool=false
RAW_BUFFERClick to expand / collapse

Summary

I observed two continuation-related failures in a local OpenClaw Slack workflow. They may be separate bugs, but they appeared in the same day while trying to continue a prior plan from Slack.

  1. A follow-up intent such as "OK, follow what you just said" was routed into an empty/main session with no prior assistant plan available, so the agent could not recover the referenced plan.
  2. Other Slack thread continuations failed before the assistant could produce content with thinking_signature_invalid / encrypted reasoning content verification errors from the Responses API path.

No secrets, Slack tokens, or full session transcripts are included below.

Environment

  • OpenClaw version: 2026.5.18
  • OpenClaw git SHA from trajectory metadata: 2ae4278
  • OS: macOS arm64, reported as macos 26.5 (arm64)
  • Runtime: Node v24.15.0
  • Provider/API path: openai, openai-responses
  • Model: gpt-5.5
  • Config details that may be relevant:
    • agents.defaults.contextInjection = "continuation-skip"
    • local OpenAI-compatible proxy base URL was used (127.0.0.1:8317)

Symptom A: follow-up intent routed into empty session

A user follow-up equivalent to:

OK, follow what you just said.

was received as a new session with:

sessionKey=agent:main:main

The agent attempted to recover context but the local session tools returned no prior context:

sessions_history => messages=[]
sessions_list => count=0

The assistant eventually replied that it could not find the plan it had just proposed.

Expected behavior:

  • When a user sends a continuation phrase such as "follow your previous plan", OpenClaw should either preserve the previous session/thread context or recover the latest assistant plan from the relevant channel/thread/session.
  • If recovery is impossible, OpenClaw should surface a clear recovery error instead of letting the agent tool-loop through empty session lookups.

Actual behavior:

  • The follow-up landed in an empty session and the prior plan was not recoverable.
  • The agent spent multiple tool calls polling session history/list with empty results.

Symptom B: Responses encrypted reasoning item verification failures

In a Slack thread continuation, subsequent turns failed before producing assistant content. Sanitized error evidence:

status=400
code=thinking_signature_invalid
type=invalid_request_error
message="The encrypted content for item rs_... could not be verified. Reason: Encrypted content could not be decrypted or parsed."
providerRuntimeFailureKind=schema
fallbackConfigured=false
fallbackStepFinalOutcome=chain_exhausted

The session trajectory for these failed turns showed:

finalStatus=error
terminalError=non_deliverable_terminal_turn
aborted=false
timedOut=false
idleTimedOut=false
didSendViaMessagingTool=false

Expected behavior:

  • OpenClaw should not resend preserved encrypted reasoning items in a way that the provider rejects.
  • If a Responses continuation chain becomes invalid, OpenClaw should drop/repair the invalid continuation state and retry with a clean prompt/history, or ask the user to start a clean session/thread.
  • The user should receive a visible error/recovery notice instead of an apparent silent stall.

Actual behavior:

  • The model request failed before content generation.
  • No fallback was configured, so the chain was exhausted.
  • From the Slack user's perspective this looked like the agent was stuck or had lost context.

Why this matters

For Slack-based agent workflows, continuation phrases are common. Losing the previous plan or failing on an invalid encrypted reasoning item makes the agent appear to forget, even when the memory framework and long-term memory files are not the root cause.

Suggested areas to inspect

  • Slack session key routing for continuation phrases and thread/main-channel boundaries.
  • Recovery behavior when sessions_history and sessions_list return empty for a continuation intent.
  • Responses API continuation state handling for encrypted reasoning items across:
    • compaction/reset/new-session boundaries
    • local OpenAI-compatible proxy/account/model changes
    • contextInjection=continuation-skip
  • Whether thinking_signature_invalid should trigger a clean retry with reasoning/encrypted continuation items removed.

Redaction note

I intentionally omitted full .jsonl session records, Slack IDs, tokens, private user content, and local private paths. I can provide more sanitized telemetry fields if maintainers specify what is useful.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#database connection#vector store#embedding generation#cache error

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

openclaw - ✅(Solved) Fix Slack continuation can lose prior plan context and Responses continuation fails with thinking_signature_invalid [1 pull requests, 1 comments, 2 participants]