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.