/new = One of "input" or "previous_response_id"or 'prompt'or 'conversation_id' must be provided.

[twin valve]

Every time I start a new session, I see:

One of "input" or "previous_response_id"or 'prompt'or 'conversation_id' must be provided.

Explain.

[viscid skiff]

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

[unreal slate]

I’ll sanity-check the docs/source before guessing — that error smells like the model provider got called with an empty request during session creation, not a config issue.

That’s an OpenAI Responses API validation error, not a meaningful assistant reply.

It means OpenClaw sent the provider an empty request: no input, no prompt, no previous_response_id, no conversation_id. For bare /new, that should not happen — /new should just rotate the session and normally reply like:

✅ New session started.

Current source has a fix for this exact class of bug:

“skip provider submission when an embedded run has no prompt… preventing empty OpenAI Responses requests from surfacing provider errors into user channels.” Fixes #71130.

So likely explanation: you’re on a version where /new/session startup can accidentally fall through into an empty OpenAI call.

First thing: please paste:

openclaw --version

openclaw status --all

If you’re older than the Apr 27-ish build, update and restart the gateway. If you’re already current and it still happens every time, that’s worth a GitHub issue with the exact version + log snippet: https://github.com/openclaw/openclaw/issues

Docs refs: /new behavior is in https://docs.openclaw.ai/tools/slash-commands, and the basic diagnostic flow is https://docs.openclaw.ai/help/faq.

[twin valve]

Is there not a hierarchy of open-source upvote development that enforces stability?

OpenClaw 2026.4.26 (be8c246)

[unreal slate]

Yep — 2026.4.26 (be8c246) is the important bit. That version predates the fix I found.

This is a known regression fixed in 2026.4.27:

empty embedded runs could submit an empty OpenAI Responses request, causing exactly that provider error.

So the practical answer is: update to 2026.4.27 or newer, then restart the gateway.

openclaw gateway restart
openclaw status --all

On the stability question: open source doesn’t really have a “hierarchy of upvotes” that enforces stability. It has maintainers, tests, bug reports, release cadence, and regressions that get fixed when they’re reproduced. This project moves fast, so occasionally a daily release catches a weird edge case — this one did, and it was fixed the next release. Annoying, but not you doing anything wrong.

If it still happens after updating past 2026.4.27, file it with your version + openclaw status --all output: https://github.com/openclaw/openclaw/issues

[twin valve]

Update Result: OK
Root: /usr/local/lib/node_modules/openclaw
Before: 2026.4.26
After: 2026.4.26

Wow.

[unreal slate]

Oof. That output is especially irritating because it says “OK” while doing a no-op. Let me check the current published package path so I don’t give you another fake update command.

Yeah — that “Wow” is earned. My previous answer was too optimistic: the fix exists past your build, but npm stable currently still resolves to 2026.4.26. I just checked:

npm view openclaw version
# 2026.4.26

So openclaw update did exactly what the current stable channel allows: Before 2026.4.26 → After 2026.4.26. The docs also note that openclaw update fetches the latest for your install type, and npm view openclaw version shows the current published version. (docs.openclaw.ai)

Short-term options:

1. Wait for the next stable npm publish — safest.
2. Try main/dev if you’re comfortable with risk:

   openclaw update --tag main --dry-run
   openclaw update --tag main