Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

OpenClaw intermittently fails on provider=github-copilot / model=gpt-5.4 with:

401 input item ID does not belong to this connection

The session gets stuck — every subsequent message returns the same error until the user runs /new.

Steps to reproduce

after upgrading last week it started to occurs having 4 agents on different channels using github-copilot provider after a few messages the error appears

Expected behavior

• classify the error correctly as replay_invalid
• surface a meaningful user message: "Session history or replay state is invalid. Use /new..."
• instead of silently repeating the raw 401

Better (automatic retry with chain drop)

When replay_invalid is detected:

1. Drop the previous_response_id / response chain linkage for this session
2. Retry the current turn as a fresh provider request
3. Only if retry also fails, surface the error to the user

This would eliminate the need for manual /new in most cases.

Actual behavior

1. Misclassification: treated as generic auth instead of replay_invalid

File: src/agents/pi-embedded-helpers.ts (minified as pi-embedded-helpers-*.js)

The error text "401 input item ID does not belong to this connection" hits the classification pipeline:

1. classifyProviderRuntimeFailureKind() is called

2. It calls isReplayInvalidErrorMessage() → checks REPLAY_INVALID_RE:

   /\bprevious_response_id\b.*\b(?:invalid|unknown|not found|does not exist|expired|mismatch)\b|...

   This regex only matches previous_response_id + specific keywords. It does NOT match "input item ID does not belong to this connection" → returns false.

3. Then classifyFailoverSignal() is called → sees HTTP status 401 → calls classifyFailoverClassificationFromHttpStatus(401, ...):

   if (status === 401 || status === 403) {
       if (message && isAuthPermanentErrorMessage(message)) return "auth_permanent";
       if (messageReason === "billing") return "billing";
       return "auth";   // ← lands here
   }

4. But classifyProviderRuntimeFailureKind doesn't have an explicit return for "auth" → falls through to return "unknown".

OpenClaw version

2026.4.12

Operating system

Linux (x64) Ubuntu 24.04

Install method

No response

Model

github-copilot/gpt-5.4

Provider / routing chain

github-copilot

Additional provider/model setup details

No response

Logs, screenshots, and evidence

**File:** `src/agents/pi-embedded-helpers.ts` (minified as `pi-embedded-helpers-*.js`)

The error text `"401 input item ID does not belong to this connection"` hits the classification pipeline:

1. `classifyProviderRuntimeFailureKind()` is called
2. It calls `isReplayInvalidErrorMessage()` → checks `REPLAY_INVALID_RE`:
   
   /\bprevious_response_id\b.*\b(?:invalid|unknown|not found|does not exist|expired|mismatch)\b|...
   
   This regex only matches `previous_response_id` + specific keywords.
   **It does NOT match `"input item ID does not belong to this connection"`** → returns `false`.

3. Then `classifyFailoverSignal()` is called → sees HTTP status 401 → calls `classifyFailoverClassificationFromHttpStatus(401, ...)`:
   
   if (status === 401 || status === 403) {
       if (message && isAuthPermanentErrorMessage(message)) return "auth_permanent";
       if (messageReason === "billing") return "billing";
       return "auth";   // ← lands here
   }
   

4. But `classifyProviderRuntimeFailureKind` doesn't have an explicit return for `"auth"` → falls through to `return "unknown"`.

5. `formatAssistantErrorText()` has no handler for `"unknown"` in this case → passes the raw error string through verbatim.

**Result:** No recovery, no chain-drop, no retry. The session stays stuck.

### 2. The `REPLAY_INVALID_RE` regex is too narrow

The regex recognizes these patterns:
- `previous_response_id` + invalid/unknown/not found/expired/mismatch
- `tool_use.input` / `tool_call.arguments` + missing/required
- `incorrect role information`
- `roles must alternate`

But does **not** recognize:
- `input item ID does not belong to this connection`

This is semantically the **same class of error**: the provider is rejecting an item reference from a prior conversation/connection. It should be classified as `replay_invalid`.

### 3. No automatic recovery for stale conversation state

Even when an error IS classified as `replay_invalid`, the current behavior is just to display:

"Session history or replay state is invalid. Use /new to start a fresh session and try again."


There is no automatic retry with a dropped response chain. The user must manually `/new`.

Impact and severity

No response

Additional information

• Multiple dates, sessions, and agents
• Always github-copilot / gpt-5.4 / openai-responses
• /new resolves it (breaks the chain)
• Token was freshly renewed and valid when the error occurred
• The error text explicitly says "connection", not token/scope/auth
• Multiple agents on the same gateway may increase the chance of hitting this (shared provider connection pool?)