run error: HTTP 404: Item with id | Friends of the Crustacean 🦞🤝 | Page 1

lapis sail Feb 16, 2026, 8:34 PM

#

consistently getting this error message on codex: run error: HTTP 404: Item with id 'rs_0eaef48ee3b207940169937e2ccdfc81989a63c8602109cd0a' 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.

I also am getting ⚠️ API rate limit reached. Please try again later when i'm using Claude models more than I was getting a few days ago even though my usage is about the same. Not sure if they're related.

ruby cedarBOT Feb 16, 2026, 8:38 PM

#

That rs_… not found / Items are not persisted when store is set to false is an OpenAI Responses API failure mode: the client is accidentally sending a reference to a prior “reasoning item” (rs_…) that was created with store:false, so OpenAI doesn’t keep it around for the next turn → 404.

In practice this usually happens after a session has some “thinking/reasoning metadata” in history and the next request tries to “replay” it.

What to do (quick)

Start a fresh session (this clears the bad history reference):
- send /new (or /reset) as a standalone message, then try Codex again.
Check your OpenClaw version (older builds were more likely to trigger this):
- paste openclaw --version
- if you’re not on the latest, update + restart (docs): https://docs.openclaw.ai/install/updating
- then openclaw gateway restart
If it still happens, paste the log snippet around the failure:
- openclaw logs --follow (or grab a short excerpt)
  Troubleshooting ladder: https://docs.openclaw.ai/gateway/troubleshooting

#

About the “⚠️ API rate limit reached” (Claude)

That one is separate: it’s Anthropic returning a 429 rate limit / quota window exhausted. Not directly related to the OpenAI 404.

FAQ section (what it means + what to check):
https://docs.openclaw.ai/help/faq#why-am-i-seeing-http-429-ratelimiterror-from-anthropic

If you tell me:

openclaw --version
whether you’re using an Anthropic API key vs Claude setup-token
and whether Codex is via OpenClaw’s openai-codex provider (vs running some separate “codex” tool)

…I can point to the most likely exact fix.

lapis sail Feb 16, 2026, 8:43 PM

#

version is 2026.2.15. 20:42:57 debug diagnostic {"subsystem":"diagnostic"} lane task done: lane=session:agent:main:main durationMs=755 active=0 queued=0

ruby cedarBOT Feb 16, 2026, 8:46 PM

#

2026.2.15 is new enough that this should be fixed for direct OpenAI/Codex runs, so if you’re still seeing the rs_… not found / store=false 404, it usually means one of these is true:

The error isn’t coming from OpenClaw’s Codex provider, but from some other “codex” integration/tool you’re running (same machine, different thing), or
Your Codex traffic is going through a non-direct baseUrl / proxy (OpenRouter, Helicone, etc.). The OpenAI “store=true” workaround is typically only applied for direct OpenAI endpoints, and proxies can still hit the store=false → rs_ not persisted → 404 path.

A couple quick checks to narrow it down:

1) Where exactly do you see the 404?

In the Discord chat reply from OpenClaw?
Or in a terminal where you’re running a Codex CLI / SDK?

If it’s in OpenClaw chat, please paste the actual error lines from:

openclaw logs --follow

(the “lane task done …” line is just a normal debug completion message; we need the part that mentions OpenAI/Codex + the 404)

#

2) Confirm the Codex model endpoint/baseUrl

Please paste (redact tokens/secrets):

openclaw models list --status

I’m specifically looking for what it shows as the provider/api/baseUrl for the Codex model. If baseUrl isn’t api.openai.com / chatgpt.com, that’s the most likely reason the 404 persists.

Quick workaround (while debugging)

If it only fails on the second message (multi-turn), you can sometimes limp along by doing one-shot Codex turns (fresh /new per task). Not ideal, but it avoids referencing prior rs_… items.

If you drop the 404 excerpt from openclaw logs --follow + the openclaw models list --status output, I can tell you which branch you’re on immediately.

lapis sail Feb 16, 2026, 8:48 PM

#

terminal. i'm using the TUI. model is gpt-5.1-codex

ruby cedarBOT Feb 16, 2026, 8:52 PM

#

If you’re seeing that in the OpenClaw TUI on gpt-5.1-codex, you’re almost certainly hitting a Codex/Responses edge case where the backend is running with store=false, and then on a later turn the request includes a prior rs_… reasoning item id → OpenAI returns:

“Item with id rs_… not found… Items are not persisted when store is set to false …”

Fastest workaround (usually fixes it)

In the TUI:

Start clean:
- /new
Turn off “thinking” (this avoids generating the reasoning items that later get referenced):
- /think off
Try your Codex prompt again.

If you want to keep some thinking, try /think minimal instead of off.

Docs for these directives: https://docs.openclaw.ai/tools/slash-commands

#

Quick confirmation (so we know which path you’re on)

In the TUI, run:

/model status

and paste what it shows for provider / api / baseUrl for the active model.

If it still happens after `/new` + `/think off`

Please paste the actual 404 block from:

openclaw logs --follow

(“lane task done…” is normal debug noise; we need the part that includes the OpenAI/Codex request + the 404.)

From there we can tell if this is:

#

a Codex backend “store must be false” behavior (so we need to strip those rs_ items from history), or
a proxy/baseUrl situation, or
something else entirely.

Also: the Claude rate-limit warning (429) is a separate issue (Anthropic quota window), not directly related to this OpenAI 404.

lapis sail Feb 16, 2026, 9:00 PM

#

worked for longer now. I'm not seeing the the 404 in the logs. just this: 20:58:35 debug cron {"module":"cron","storePath":"/home/mtdohert/.openclaw/cron/jobs.json"} {"nextAt":1771855200000,"delayMs":60000,"clamped":true} cron: timer armed
20:58:36 info web-heartbeat {"module":"web-heartbeat","runId":"c57a6960-6cee-4e2c-a075-68a5b105ec96"} {"connectionId":"d69d1296-00d0-4618-ada4-a559398e0a9d","reconnectAttempts":0,"messagesHandled":0,"lastMessageAt":null,"authAgeMs":300002.7102050781,"uptimeMs":300842} web gateway heartbeat
20:59:35 debug cron {"module":"cron","storePath":"/home/mtdohert/.openclaw/cron/jobs.json"} {"nextAt":1771855200000,"delayMs":60000,"clamped":true} cron: timer armed
20:59:36 info web-heartbeat {"module":"web-heartbeat","runId":"c57a6960-6cee-4e2c-a075-68a5b105ec96"} {"connectionId":"d69d1296-00d0-4618-ada4-a559398e0a9d","reconnectAttempts":0,"messagesHandled":0,"lastMessageAt":null,"authAgeMs":360003.7102050781,"uptimeMs":360843} web gateway heartbeat

ruby cedarBOT Feb 16, 2026, 9:00 PM

#

Yep — those log lines are totally normal.

cron: timer armed is just the scheduler waking up once a minute to see if anything’s due.
web gateway heartbeat is the dashboard/control UI connection doing its keepalive.

So if you’re no longer seeing the 404 anywhere, you’re good.

Why `/think off` helped (so it doesn’t come back)

That 404 is triggered when Codex ends up with an rs_… “reasoning item id” in the transcript, and then a later turn references it while the backend is effectively running with store=false (so that rs_… item isn’t retrievable anymore). Turning thinking off/minimal avoids generating those reasoning items in the first place.

What to do if it returns

In the TUI:

/new
/think off (or /think minimal)
retry

If you want, also run /model status and paste it next time it happens — that shows the provider/api/baseUrl and helps confirm which backend path is in play.

#

Also: the Claude “API rate limit reached” warning is separate (Anthropic 429 window/quota); it can happen even if Codex is fine.

If this fixed it, please mark the solution in the thread (right-click the solution message → Apps → ✅ Mark Solution) so Answer Overflow indexes it.

lapis sail Feb 16, 2026, 9:01 PM

#

sorry no i'm still getting the 400 error it just took longer to show up

ruby cedarBOT Feb 16, 2026, 9:03 PM

#

Got it — if it takes a while to show up, that strongly suggests it’s multi‑turn transcript state drifting into a shape the OpenAI/Codex Responses API rejects (usually: a previous turn leaves behind an rs_… reasoning item reference, then a later request tries to include/replay it while the backend is effectively store=false → boom).

To pin down which exact path you’re on, I need two concrete snippets:

The exact “run error: HTTP …” line from the TUI (including whether it’s 400 vs 404, and the rs_… id if shown)
In the TUI, run:

/model status
and paste the output (it includes the important bits: provider / api / baseUrl / auth profile)

Then reproduce once more while tailing logs:

openclaw logs --follow

and paste the log block around the failure (10–30 lines). The “cron timer armed” / “web-heartbeat” lines aren’t related, so we’re looking for the section that mentions OpenAI/Codex + the HTTP error.

Workarounds while we debug

#

Keep Codex sessions shorter: do a /new before starting a new coding task (this avoids carrying the problematic rs_… references forward).
Keep /think off (or /think minimal) — it often delays/avoids the creation of those rs_… items, but apparently doesn’t eliminate it in your case.

Once you paste (a) the TUI error line and (b) /model status, I can tell whether:

this is going through openai-codex (chatgpt.com/backend-api/...) vs openai (api.openai.com/v1), and
whether it’s a known “store=false + reasoning replay” mismatch (likely needs a code-side transcript sanitization/workaround, not something you can config away).

If it turns out to be that class of bug, the right next step is a GitHub issue with those snippets so it can be fixed properly.

lapis sail Feb 16, 2026, 9:07 PM

#

run error: 400 Item 'rs_061925220b3dd93800699384a9ab38819782c24a549673dcb9' of type 'reasoning' was provided
without its required following item. it wont let me do /model status but i can do /openai status which gives me that same 400 item error

ruby cedarBOT Feb 16, 2026, 9:10 PM

#

That 400 is the other common sibling of the rs_… not found error, and it means the same underlying thing: your next request is including an orphaned reasoning item (rs_…) in the input history, but the API expects that reasoning item to be immediately followed by another item (message/tool call/etc). When that pairing gets broken once, the whole thread can become “poisoned” and every subsequent turn fails.

This is a known Codex/Responses API failure mode (upstream issue): https://github.com/openai/codex/issues/1498

Quick way to get unstuck

Exit the session and start a fresh one (don’t “resume” the broken thread).
- In Codex TUI: /exit then restart codex (or start a new session another way).

Make it happen less often (Codex CLI config)

Codex CLI has config knobs to stop sending/using reasoning metadata. In ~/.codex/config.toml, try:

model_supports_reasoning_summaries = false
model_reasoning_summary = "none"

(These keys are in the official config reference: https://developers.openai.com/codex/config-reference/)

#

You can also test it for one run via CLI overrides (codex --config/-c key=value), before changing the file.

If you want, paste two things and I’ll suggest the least-painful setting

your Codex CLI version (codex --version)
whether you’re using ChatGPT login or an API key / custom provider base_url

Because this shows up more with some provider setups than others.

lapis sail Feb 16, 2026, 9:16 PM

#

i'm using an API key. and i'm also using the CLI from my raspberry pi. i put in openclaw codex --version in the CLI and got back 2026.2.15 but i think thats for openclaw not for codex?

ruby cedarBOT Feb 16, 2026, 9:18 PM

#

Yep — openclaw … --version is OpenClaw’s version (2026.2.15). That’s not the OpenAI “Codex CLI” version.

But also: based on the error text you pasted, you’re not hitting the Codex CLI at all here — you’re hitting the OpenAI Responses API via OpenClaw, and it’s rejecting your session history:

Item 'rs_…' of type 'reasoning' was provided without its required following item

Once a session gets into that state, every subsequent turn can fail (even things like /openai status if that command ends up sending a normal model turn).

Get unstuck (works even when the model is “poisoned”)

In the OpenClaw TUI, send as a standalone message:

/new

Then immediately set:

/think off

#

and continue.

If /new doesn’t recover it, do it from the shell:

openclaw gateway restart

then reopen the TUI and start fresh.

Confirm what backend you’re actually using (important)

In a separate terminal (not inside the broken TUI session), run and paste:

openclaw models status

#

I want to see the line for the model you’re using (provider/api/baseUrl). With an API key, you should typically be on the openai provider (Responses API). If it’s going through something else (proxy/baseUrl), it changes the workaround.

Reality check / next step

This specific “reasoning item missing required following item” error is a known upstream Responses/Codex-family failure mode when the client replays a reasoning item but the paired next item isn’t present in the reconstructed input. OpenClaw can work around some variants, but if you can reproduce it reliably, it’s worth filing a GitHub issue with:

the exact error line (you already have it)
openclaw --version
openclaw models status output (redact keys)
a short log excerpt around the failing request (openclaw logs --follow, 20-50 lines)

If you paste openclaw models status here, I’ll tell you which exact provider path you’re on and what mitigation is most likely to stick (beyond “/new when it breaks”).

lapis sail Feb 16, 2026, 9:30 PM

#

Key │ Kind │ Age │ Model │ Tokens │
├─────────────────────────────────────────────────────────────────┼────────┼─────────┼───────────────┼────────────────┤
│ agent:main:main │ direct │ 1m ago │ gpt-5.1-codex │ 14k/400k (4%) │
│ agent:main:discord:channel:1473… │ group │ 1h ago │ gpt-5.1-codex │ 0.0k/400k (0%) │
│ agent:main:discord:channel:1472… │ group │ 1h ago │ gpt-5.1-codex │ 0.0k/400k (0%)

#

sorry wrong thing. one second

#

Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/main/agent
Default : openai/gpt-5.1-codex
Fallbacks (0) : -
Image model : -
Image fallbacks (0): -
Aliases (3) : GPT -> openai/gpt-5.1-codex, sonnet -> anthropic/claude-sonnet-4-5, opus -> anthropic/claude-opus-4
Configured models (7): openai/gpt-5.1-codex, openai/gpt-4o, anthropic/claude-sonnet-4-5, openai/gpt-5-codex, anthropic/claude-sonnet-4, anthropic/claude-opus-4, anthropic/claude-sonnet-4-0

Auth overview
Auth store : ~/.openclaw/agents/main/agent/auth-profiles.json
Shell env : off
Providers w/ OAuth/tokens (1): openai (1)

anthropic effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | anthropic:default=sk-ant-a...DrvDnwAA
openai effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=1, api_key=0) | openai:manual=token:sk-proj-...O6r1zmAA | env=echo exp.../.bashrc | source=env: OPENAI_API_KEY

ruby cedarBOT Feb 16, 2026, 9:35 PM

#

Yep — openclaw --version (or what you ran) is OpenClaw’s version. It’s not the OpenAI “Codex CLI” version.

And the 400 you’re getting:

Item 'rs_…' of type 'reasoning' was provided without its required following item

is an OpenAI Responses API transcript-shape error (it happens when a prior turn leaves an orphaned reasoning item in the saved history). Once that gets into a session, the session is basically “poisoned” and every follow-up turn can keep failing.

Practical way to recover (OpenClaw)

In the OpenClaw TUI, send exactly this as a standalone message:

/new

Then immediately:

/think off

If you ever interrupt/abort a run (Ctrl+C, timeouts, connection hiccup), it’s worth doing /new right after — that’s when these dangling rs_… items most often get left behind.

#

Quick diagnostic (to confirm the “poisoned by an aborted run” theory)

Run this in a normal shell (not inside the broken conversation turn):

openclaw sessions --json

Look at the agent:main:main entry and see if it has abortedLastRun: true around the time the 400 starts. If yes, that’s a strong signal an incomplete assistant turn got persisted.

What I need from you to turn this into a real fix

This likely needs an OpenClaw-side workaround (dropping dangling reasoning blocks from history more aggressively). To file a useful bug report, grab:

openclaw --version
openclaw logs --follow

#

…and paste the log block that includes the 400, plus whether you were doing anything like stopping a run mid-stream.

If you want, paste the openclaw sessions --json entry for agent:main:main (redact anything sensitive) and I’ll tell you exactly what to look for + what to include in a GitHub issue.

#

Yep — that table you pasted is openclaw sessions output (session list), so it confirms you’re running OpenClaw TUI with openai/gpt-5.1-codex.

That 400:

Item 'rs_…' of type 'reasoning' was provided without its required following item

is the OpenAI Responses API rejecting your saved session history (usually after an interrupted/partial assistant turn leaves a dangling reasoning item). It’s a known upstream failure mode in Codex/Responses-land.

What to do when it happens (fast recovery)

In the OpenClaw TUI, send as a standalone message:

/new

(that should work even if the model is “poisoned”, because it’s a gateway command, not a model call)

If you still can’t recover:

openclaw gateway restart

#

reopen TUI

Make it hurt less (recommended config)

Since you already have Claude configured, add a fallback so you’re not dead-in-the-water when OpenAI rejects a turn:

{
  agents: {
    defaults: {
      model: {
        primary: "openai/gpt-5.1-codex",
        fallbacks: ["anthropic/claude-sonnet-4-5"],
      },
    },
  },
}

#

Next step (so it can actually get fixed)

If you can, grab the log block right when it starts happening:

openclaw logs --follow

and paste ~20-50 lines around the 400. Also mention whether you hit Ctrl+C / aborted a run shortly before it started.

If you’re up for it, file a bug on OpenClaw with:

the exact 400 line
openclaw --version (2026.2.15)
your openclaw models status output (the one showing openai/gpt-5.1-codex + API key)
the log excerpt

GitHub issues: https://github.com/openclaw/openclaw/issues

lapis sail Feb 16, 2026, 9:44 PM

#

it says there's three sessions open but i think it should just be the agent: main:main. i dont know how the discord ones got htere. i don't have my discord linked. mtdohert@openclawtest:~ $ openclaw sessions --json
{
"path": "/home/mtdohert/.openclaw/agents/main/sessions/sessions.json",
"count": 3,
"activeMinutes": null,
"sessions": [
{
"key": "agent:main:main",
"kind": "direct",
"updatedAt": 1771277844166,
"ageMs": 14379,
"sessionId": "",
"systemSent": true,
"abortedLastRun": false,
"thinkingLevel": "off",
"inputTokens": 6174,
"outputTokens": 1183,
"totalTokens": 13232,
"totalTokensFresh": true,
"model": "gpt-5.1-codex",
"contextTokens": 400000
},
{
"key": "agent:main:discord:channel:1473047595063709867",
"kind": "group",
"updatedAt": 1771273406509,
"ageMs": 4452036,
"sessionId": "",
"systemSent": false,
"abortedLastRun": false,
"inputTokens": 0,
"outputTokens": 0,
"totalTokens": 0,
"totalTokensFresh": true,
"model": "gpt-5.1-codex",
"contextTokens": 400000
},
{
"key": "agent:main:discord:channel:1472786307406368791",
"kind": "group",
"updatedAt": 1771273401740,
"ageMs": 4456805,
"sessionId": "",
"systemSent": false,
"abortedLastRun": false,
"inputTokens": 0,
"outputTokens": 0,
"totalTokens": 0,
"totalTokensFresh": true,
"model": "gpt-5.1-codex",
"contextTokens": 400000

ruby cedarBOT Feb 16, 2026, 9:46 PM

#

Those “discord” entries in openclaw sessions are just stored session keys, not “open connections”, and they aren’t affecting your agent:main:main TUI session (they’re at 0 tokens / 0 usage).

How they got there is usually one of:

You (or the installer/wizard) had Discord configured at some point (even briefly), the gateway saw messages, and it kept the session metadata.
You copied ~/.openclaw from another machine that did have Discord enabled.
Less commonly: you pointed your CLI at a gateway that had Discord enabled (remote mode), but your path looks local to the Pi.

Check whether Discord is actually configured right now

On the Pi, run:

openclaw channels status --probe
openclaw config get channels.discord

If Discord is not configured, those old session rows are harmless noise and you can ignore them.

#

About the 400 `rs_... reasoning ... required following item`

That error is coming from OpenAI Responses rejecting the history for the current session. The Discord session rows are unrelated.

When it hits, the reliable recovery is:

in the OpenClaw TUI: /new (standalone message)

Note: /openai status is not an OpenClaw command, so it’ll just get sent to the model and fail the same way. Use /status or /model status (those are gateway-handled).

If you want, paste the output of /model status from inside the TUI before it breaks (provider/api/baseUrl). That tells us which exact OpenAI endpoint path you’re on and helps determine the best mitigation (e.g., switching to openai/gpt-4o when the session gets poisoned, or setting a Claude fallback).

lapis sail Feb 16, 2026, 9:48 PM

#

i get this error message when i do /model status model set failed: Error: model not allowed: openai/status
connected | error
agent main | session main (openclaw-tui) | openai/gpt-5.1-codex | tokens 0/400k (0%)

ruby cedarBOT Feb 16, 2026, 9:49 PM

#

That error is just OpenClaw interpreting what you typed as a model name:

openai/status looks like a provider/model ref
so OpenClaw thinks you’re trying to switch to model provider=openai model=status
and then correctly says “model not allowed” because status isn’t a model

Use these instead (TUI)

Check status:

/status ← overall status
/model status ← shows current model/provider details

Switch models:

/model (opens the picker)
or directly: /model openai/gpt-4o

There is no /openai status command in OpenClaw (so it won’t do what you expect).

#

CLI equivalents (outside the TUI)

openclaw status --usage
openclaw models status

If you’re currently in the “poisoned” state with the rs_… reasoning … required following item 400, the quickest recovery is still:

/new (standalone) in the TUI, then continue.

lapis sail Feb 16, 2026, 9:54 PM

#

yeah /new doesn't work

#

it gives the same 400 error when i start again every time

ruby cedarBOT Feb 16, 2026, 9:59 PM

#

Those Discord-looking keys in sessions.json are just old session metadata (not “open connections”), and they’re not why your TUI run is breaking.

The big red flag in your JSON is this:

"sessionId": "" (empty string) for agent:main:main

That’s not normal (it should be a UUID). When the session id / transcript bookkeeping is in a weird state like that, resets can behave badly, and you can get stuck in these OpenAI “reasoning item … required following item” loops.

Fix: wipe only the session store/transcripts (keep config + auth)

On the Pi:

Stop the gateway (or just restart it after step 2):

openclaw gateway stop

Move the sessions directory out of the way (this is reversible):

#

mv ~/.openclaw/agents/main/sessions ~/.openclaw/agents/main/sessions.bak

Start again:

openclaw gateway start

Verify you now get a real sessionId:

openclaw sessions --json

agent:main:main should show a non-empty sessionId (UUID-like).

Then re-open the TUI and try again.

#

Why this helps the 400

That OpenAI 400 is triggered by corrupted/invalid replayed history (dangling rs_… reasoning items). Moving ~/.openclaw/agents/main/sessions/ forces OpenClaw to start with a clean transcript/state for that agent.

If after this you can reproduce the 400 again after some time, it’s worth filing an issue (it’s likely an OpenClaw-side sanitization edge case). Include:

the exact 400 line
openclaw --version
openclaw models status
a short openclaw logs --follow excerpt around the failure

lapis sail Feb 16, 2026, 10:00 PM

#

i removed the sessionId before sending you the paste. this morning when i was working on something i accidentally reset my agent and it deleted a bunch of credentials and things.

ruby cedarBOT Feb 16, 2026, 10:02 PM

#

/new not “working” here is consistent with what you’re seeing: /new resets the session, but then it immediately runs a tiny “greeting” model call. If every OpenAI call is currently failing with that 400, you’ll still see an error and it looks like /new didn’t do anything.

The important clue in your openclaw sessions --json output is:

sessionId: "" for agent:main:main

That’s a busted session entry, and it can cause OpenClaw to keep replaying bad transcript state.

Hard reset the session store (no guessing, reversible)

This wipes chat history for the agent, but keeps config + auth profiles.

On the Pi:

openclaw gateway stop

#

# backup (reversible)
mv ~/.openclaw/agents/main/sessions ~/.openclaw/agents/main/sessions.bak.$(date +%s)

openclaw gateway start

Now verify it’s actually clean:

openclaw sessions --json

Expected: count should be 0 (until you send a message), and once you do send one, the new agent:main:main entry should have a real UUID sessionId (not empty).

If openclaw sessions --json still shows the old entries after the mv, you’re almost certainly looking at a different state dir/profile than the gateway is using. In that case paste:

#

openclaw status
openclaw gateway status

Immediate workaround (so you can keep working even if Codex glitches again)

Since you have no fallbacks, any OpenAI 400 kills the run. Add a fallback model:

{
  agents: {
    defaults: {
      model: {
        primary: "openai/gpt-5.1-codex",
        fallbacks: ["openai/gpt-4o", "anthropic/claude-sonnet-4-5"],
      },

#

    },
  },
}

That way if gpt-5.1-codex throws that “reasoning required following item” 400, OpenClaw can still answer using the fallback instead of bricking the session.

Also: the agent:main:discord:... session keys are harmless leftovers; they’re not “active” and they won’t break the TUI run.

If you do the mv .../sessions reset and the very first message in a brand new session still returns that same 400 with an rs_... id, paste the 20–50 log lines around it from:

openclaw logs --follow

#

/new is being handled — it’s just that a bare /new immediately triggers a tiny “fresh session greeting” model call, and that call is still hitting the same OpenAI 400, so it looks like “/new didn’t work”.

A couple ways to break out of the “poisoned history” loop without nuking creds:

1) Start a truly fresh session key (no history)

In the TUI:

/session scratch
then send a normal message (e.g. hi)

If that works, your old main session history is what’s triggering the rs_… reasoning … required following item error.

2) Force a model change (this can auto-clean the bad `rs_…` block)

In the TUI:

/model openai/gpt-4o (or pick it via Ctrl+L)
send a simple message like test

#

then switch back: /model openai/gpt-5.1-codex

OpenClaw has a “when model changes, downgrade/remove dangling OpenAI reasoning blocks” path; this often fixes exactly this error.

3) Use `/new` but not bare

Bare /new runs the greeting prompt. Instead do:

/new hi

(or, if OpenAI is still unhappy, reset + switch provider in one go)

/new sonnet hi

That both resets and moves the session to Claude Sonnet for the first message.

#

Re: the “discord” sessions showing up

Those entries in sessions.json are just old stored keys/metadata. They are not active connections and not related to your TUI error (they’re at 0 tokens).

Re: “I ran reset and it deleted creds”

Totally different command: openclaw reset is destructive and can wipe config/creds depending on scope. /new only resets the chat session, not your auth profiles.

If you tell me which of the 3 options above works (especially /session scratch), I can point to the cleanest “fix main session” path.

lapis sail Feb 17, 2026, 2:53 AM

#

i ended up starting over the agent with a clean build

twilit marlin Feb 17, 2026, 3:13 AM

#

I've been fighting the same issues all day. I even switched to Anthropic models but could not get the error to go away. I eventually just told my bot to downgrade to openclaw version 2026.02.14 and it's been fine ever since

ruby cedarBOT Feb 17, 2026, 3:15 AM

#

That’s a super useful datapoint, thanks. If 2026.2.14 makes the rs_… reasoning … required following item / rs_… not found class of errors disappear, that strongly points to a regression in 2026.2.15 (at least for the OpenAI Responses/Codex path).

If you’re currently stuck on 2026.2.15, the pragmatic workaround is to downgrade:

(Optional but smart) back up state first:

cp -a ~/.openclaw ~/.openclaw.bak

Downgrade:

openclaw update --tag 2026.2.14

Restart:

#run error: HTTP 404: Item with id

What to do (quick)

About the “⚠️ API rate limit reached” (Claude)

1) Where exactly do you see the 404?

2) Confirm the Codex model endpoint/baseUrl

Quick workaround (while debugging)

Fastest workaround (usually fixes it)

Quick confirmation (so we know which path you’re on)

If it still happens after /new + /think off

Why /think off helped (so it doesn’t come back)

What to do if it returns

Workarounds while we debug

Quick way to get unstuck

Make it happen less often (Codex CLI config)

If you want, paste two things and I’ll suggest the least-painful setting

Get unstuck (works even when the model is “poisoned”)

Confirm what backend you’re actually using (important)

Reality check / next step

Practical way to recover (OpenClaw)

Quick diagnostic (to confirm the “poisoned by an aborted run” theory)

What I need from you to turn this into a real fix

What to do when it happens (fast recovery)

Make it hurt less (recommended config)

Next step (so it can actually get fixed)

Check whether Discord is actually configured right now

About the 400 rs_... reasoning ... required following item

Use these instead (TUI)

CLI equivalents (outside the TUI)

Fix: wipe only the session store/transcripts (keep config + auth)

Why this helps the 400

Hard reset the session store (no guessing, reversible)

Immediate workaround (so you can keep working even if Codex glitches again)

1) Start a truly fresh session key (no history)

2) Force a model change (this can auto-clean the bad rs_… block)

3) Use /new but not bare

Re: the “discord” sessions showing up

Re: “I ran reset and it deleted creds”

If it still happens after `/new` + `/think off`

Why `/think off` helped (so it doesn’t come back)

About the 400 `rs_... reasoning ... required following item`

2) Force a model change (this can auto-clean the bad `rs_…` block)

3) Use `/new` but not bare