openclaw - 💡(How to fix) Fix bug: /btw fails with cli-proxy-api OpenAI auth: 404 item not found when store=false [1 participants]

Bug type

Bug

Summary

/btw fails with OpenAI auth routed through cli-proxy-api, returning:

⚠️ /btw failed: 404 Item with id 'rs_resp_...' not found. Items are not persisted when store is set to false. Try again with store set to true, or remove this item from your input.

This appears to be a BTW-specific variant of the known Responses API store=false problem, but in this case it happens when using OpenAI auth via cli-proxy-api and invoking /btw from Control UI.

Steps to reproduce

1. Configure OpenClaw to use OpenAI auth via cli-proxy-api
2. Use a model/provider path that goes through the OpenAI Responses-style flow
3. Open a normal chat session in Control UI
4. Send a normal message so the session has current context
5. Run a /btw ... command
6. Observe the failure

Expected behavior

/btw should return a side result successfully, without requiring persisted upstream item ids that are unavailable when store=false.

Actual behavior

/btw fails with:

404 Item with id 'rs_resp_...' not found. Items are not persisted when store is set to false. Try again with store set to true, or remove this item from your input.

OpenClaw version

2026.4.2 (d74a122)

Operating system

macOS 26.4 (arm64)

Install method

npm global / brew-installed local environment

Model

Observed in a setup using OpenAI auth via cli-proxy-api (exact routed upstream model may vary depending on proxy resolution)

Provider / routing chain

OpenClaw -> cli-proxy-api -> OpenAI-auth-backed upstream

Config file / key location

Configured locally via OpenClaw models/provider config using cli-proxy-api

Additional provider/model setup details

• Auth path uses cli-proxy-api rather than direct OpenAI API key auth
• Failure occurs specifically on /btw
• Control UI is the triggering surface
• There is also a separate known issue where Control UI does not yet render chat.side_result, but this report is about the backend/provider failure before rendering

Logs, screenshots, and evidence

Observed error message:

⚠️ /btw failed: 404 Item with id 'rs_resp_09ca5d7d4a5dd7dd0169cf1c9a7ca0819bb6975198341f59b9_0' not found. Items are not persisted when store is set to false. Try again with store set to true, or remove this item from your input.

Additional context:

• Normal chat works
• /btw is the failing path
• The error strongly suggests BTW is referencing a prior Responses item id that is unavailable because the upstream run was not stored persistently

Impact and severity

• /btw is unusable in this routing configuration
• Affects side-question workflow specifically
• Likely indicates BTW is reusing response/item references in a way that is incompatible with store=false providers or proxies

Additional information

Potential root cause:

• /btw appears to snapshot current session context, but may still be passing provider-level prior item references (rs_* / rs_resp_*) into the follow-up request path
• When the upstream auth/provider chain does not persist items (store=false), those references cannot be resolved and the request fails

Suggested fix directions:

1. For /btw, prefer text/context snapshot replay instead of provider item-id chaining
2. Avoid sending prior response/item references when the active provider/proxy path does not guarantee persistence
3. If BTW depends on item chaining, ensure store=true is enforced when supported

Possibly related existing issues:

• #53333 (Control UI missing chat.side_result consumer)
• #55376 (/btw fails with 'No BTW response generated')
• #16803 / #12885 / #25058 (Responses API store=false -> item not found family)