openclaw - 💡(How to fix) Fix [Bug]: bare /reset triggers OpenAI Responses API HTTP 400 (empty input/previous_response_id/prompt/conversation_id) [2 comments, 2 participants]

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

On openclaw v2026.4.26, sending a bare /reset to a Telegram-bridged agent on the openai-codex provider triggers an automatic LLM call before any user input arrives; the runtime constructs a Responses API request with all four required identifying fields empty, OpenAI returns HTTP 400 with a server-authored error message, and the runtime forwards that verbatim error string to the Telegram channel as the bot's reply.

Steps to reproduce

1. Configure an agent with provider: openai-codex, model: gpt-5.5, and a Telegram bot bridge.
2. From an authorized chat, send a bare /reset (no trailing text).
3. Observe the bot's reply: it contains the verbatim OpenAI server error string One of "input" or "previous_response_id" or 'prompt' or 'conversation_id' must be provided.
4. Confirm in the user-scope gateway journal:

[agent/embedded] embedded run agent end: runId=<uuid> isError=true model=gpt-5.5 provider=openai-codex error=One of "input" or "previous_response_id"or 'prompt'or 'conversation_id' must be provided.

Followed within ~500ms by [telegram] sendMessage ok to the affected chat.

Reproduced empirically on two independent hosts on 2026-04-29 (11:25 PDT and 12:04 PDT).

Expected behavior

Bare /reset should produce a normal session-start agent reply (greeting or per-config startup-context content). The agent runtime should not invoke an LLM with a malformed Responses API body, and any internal validation failure should not be forwarded to the user channel as the bot's reply.

Reference for "normal session-start": when the same bridge handles /reset <some text> (with trailing text), the agent reply is normal and no error fires. The empty-trailing-text path is the differentiator.

Actual behavior

Bare /reset on Telegram produces the OpenAI server's 400 error string as the bot's first message. The error body is captured by the runtime's [agent/embedded] log layer and then forwarded verbatim to the Telegram channel via sendMessage.

We traced the chain through the loaded dist/ source on a v2026.4.26 install. Findings (every line cited below was verified by direct probe of the installed source):

1. Inbound dispatch reaches dispatchInboundMessage at dist/dispatch-gfPCX7Ws.js:1158, which calls dispatchReplyFromConfig at :219-225 and reaches replyResolver(ctx, options, replyConfig) at :706-708.
2. A reset-tail dispatch path exists at dist/dispatch-gfPCX7Ws.js:819 gated on ctx.AcpDispatchTailAfterReset === true, which fires hookRunner.runReplyDispatch({..., isTailDispatch: true, ...}) after reset processing. We believe this is where the post-reset auto-invocation originates; the upstream code that sets the flag is not in the loaded scope.
3. runEmbeddedPiAgent is invoked with params.prompt (entry at dist/pi-embedded-aAN5CWPb.js:1486). The wrapper at :998 (async function runEmbeddedAttemptWithBackend(params)) returns runAgentHarnessAttemptWithFallback(params) from dist/selection-D9uTvvsw.js.
4. An empty-prompt skip guard exists at dist/selection-D9uTvvsw.js:7470:

   if (!skipPromptSubmission && !promptSubmission.runtimeOnly && !hasPromptSubmissionContent({
       prompt: promptSubmission.prompt,
       messages: activeSession.messages,
       imageCount: imageResult.images.length
   })) {
       skipPromptSubmission = true;
       log$4.info(`embedded run prompt skipped: empty prompt/history/images runId=${params.runId} ...`);
   }

In our captured failures, the embedded run prompt skipped log line is not emitted for the failing runId. Either this code path is bypassed by the auto-fire trigger, or hasPromptSubmissionContent returns true at this layer (prompt non-empty here) and the empty body is constructed downstream in transport. 5. Submission boundary at dist/selection-D9uTvvsw.js:7584-7608 calls await abortable(activeSession.prompt(promptSubmission.prompt)) (with a runtimeOnly variant nearby). 6. Provider hooks are spread in at dist/openai-codex-provider-Bn2XPXMP.js:393: ...buildOpenAIResponsesProviderHooks(), imported at :18 from ./shared-BKy5I07-.js. 7. dist/shared-BKy5I07-.js (full 60 lines verified) contains no input validation. Line 5 imports OPENAI_RESPONSES_STREAM_HOOKS from ./provider-stream-7qasVyCl.js. The function at :39-49 returns the hook bundle:

   function buildOpenAIResponsesProviderHooks(options) {
       return {
           buildReplayPolicy: buildOpenAIReplayPolicy,
           prepareExtraParams: (ctx) => defaultOpenAIResponsesExtraParams(ctx.extraParams, options),
           ...OPENAI_RESPONSES_STREAM_HOOKS,
           wrapStreamFn: wrapOpenAIResponsesProviderStreamFn,
           resolveTransportTurnState: resolveOpenAIResponsesTransportTurnState,
           resolveWebSocketSessionPolicy: resolveOpenAIResponsesWebSocketSessionPolicy
       };
   }

The actual POST /v1/responses body assembly is in provider-stream-7qasVyCl.js, which is the only loaded-context-adjacent file we did not inspect.

The inbound /v1/responses endpoint at dist/openresponses-http-D2SenRnn.js:725 does have a local empty-input guard:

if (!prompt.message) {
    // ... "Missing user message in `input`."
}

So inbound rejects malformed requests locally; outbound does not appear to mirror this.

OpenClaw version

2026.4.26

Operating system

Ubuntu 24.04 (WSL2 on Windows 11)

Install method

npm global via Linuxbrew (npm root -g = /home/<user>/.npm-global/lib/node_modules)

Model

openai-codex/gpt-5.5

Provider / routing chain

openclaw -> openai-codex provider -> OpenAI Responses API (POST /v1/responses)

Additional provider/model setup details

Telegram channel is the user-facing surface (sessionKey shape agent:main:telegram:direct:<chatid>). The agent has memory-qdrant plugin v1.0.15 enabled with autoCapture: true, autoRecall: true against a local Qdrant container at localhost:6333 (collection openclaw_memories, 384-dim Cosine embeddings via @xenova/transformers).

Plugin config under plugins.entries.memory-qdrant. Provider configuration follows the standard openclaw openai-codex shape; no per-agent override of models.providers.openai-codex is required to reproduce.

Logs, screenshots, and evidence

=== Failing runId capture from gateway journal (timestamps in PDT) ===

Apr 29 11:25:00 ... 2026-04-29T11:25:00.058-07:00
[agent/embedded] embedded run agent end:
  runId=7c269a34-79ce-42f1-911c-37d9b52937a0 isError=true
  model=gpt-5.5 provider=openai-codex
  error=One of "input" or "previous_response_id"or 'prompt'or 'conversation_id' must be provided.
  rawError=One of "input" or "previous_response_id"or 'prompt'or 'conversation_id' must be provided.

Apr 29 11:25:00 ... 2026-04-29T11:25:00.538-07:00
[telegram] sendMessage ok chat=<redacted> message=690

=== Verified citations from dist/ on Linuxbrew npm-global v2026.4.26 install ===

selection-D9uTvvsw.js:7470 [total 8402 lines]
  if (!skipPromptSubmission && !promptSubmission.runtimeOnly && !hasPromptSubmissionContent({

shared-BKy5I07-.js:5 [total 60 lines]
  import { a as OPENAI_RESPONSES_STREAM_HOOKS } from "./provider-stream-7qasVyCl.js";

shared-BKy5I07-.js:39
  prepareExtraParams: (ctx) => defaultOpenAIResponsesExtraParams(ctx.extraParams, options),

openresponses-http-D2SenRnn.js:725 [total 1130 lines]
  if (!prompt.message) {

pi-embedded-aAN5CWPb.js:1486 [total 3061 lines]
  async function runEmbeddedPiAgent(params) {

pi-embedded-aAN5CWPb.js:998
  async function runEmbeddedAttemptWithBackend(params) {

dispatch-gfPCX7Ws.js:819 [total 1211 lines]
  if (ctx.AcpDispatchTailAfterReset === true) {

dispatch-gfPCX7Ws.js:1158
  async function dispatchInboundMessage(params) {

openai-codex-provider-Bn2XPXMP.js:393 [total 464 lines]
  ...buildOpenAIResponsesProviderHooks(),

openai-codex-provider-Bn2XPXMP.js:18
  import { n as buildOpenAIResponsesProviderHooks, ... } from "./shared-BKy5I07-.js";

=== memory-qdrant plugin v1.0.15 verified citations ===

~/.openclaw/extensions/memory-qdrant/index.js:321 [total 701 lines]
  const MEMORY_TRIGGERS = [

~/.openclaw/extensions/memory-qdrant/index.js:351
  return MEMORY_TRIGGERS.some(r => r.test(text));

(MEMORY_TRIGGERS body shows autoCapture is selective: matches phrases like
"remember", "prefer", "decided", "my X is", "always", "never" — so the
collection is biased toward explicit fact statements and does not record
full conversation transcripts.)

Impact and severity

• Affected: every agent that uses the openai-codex provider on a Telegram bridge and is exposed to bare /reset. In our 4-host federation deployment, all 6 agents match this profile.
• Severity: High. The verbatim OpenAI server error string is delivered to the user channel as the bot's first reply. End users cannot distinguish this from a runtime fault, and bare /reset is a documented part of the Telegram UX.
• Frequency: Always, on the bare-/reset path. Trailing-text variants (/reset <text>) do not exhibit the bug.
• Consequence: Bare /reset is unusable on Telegram; users must be trained to use /reset <any text> instead. Conversational continuity post-reset is also degraded (separate observation, see Additional information).

Additional information

Tested workarounds (both insufficient):

1. agents.defaults.startupContext.enabled: false — disables one auto-fire path (the daily-memory prelude builder). Hot-reloads cleanly via the v2026.4.26 config-watcher (which emits [reload] config change detected; evaluating reload (<key.path>) within ~1s of file write). Outcome: insufficient. Verbatim 400 still fires post-edit.

2. hooks.internal.entries["session-memory"].llmSlug: false — supposed to skip the generateSlugViaLLM call in the bundled session-memory hook (dist/bundled/session-memory/handler.js:194-200). Hot-reload signature confirmed deep-key-aware: [reload] config change detected; evaluating reload (hooks.internal.entries.session-memory). Outcome: empirically vestigial. Verbatim 400 still fires.

3. Re-enable startupContext with full schema-default sub-keys (per dist/runtime-schema-TpYHXgGk.js:3239-3285): enabled: true, applyOn: ["new", "reset"], dailyMemoryDays: 2, maxFileBytes: 16384, maxFileChars: 1200, maxTotalChars: 2800, on a host with current daily-memory files at ~/.openclaw/workspace/memory/YYYY-MM-DD.md. Multi-key reload signature observed listing all 6 changed sub-keys atomically. Outcome: no observable user-facing change. Rolled back.

Suggested fix candidates (from loaded evidence, not all verifiable from outside):

• Add empty-input guard to OPENAI_RESPONSES_STREAM_HOOKS in provider-stream-7qasVyCl.js mirroring the inbound preflight at dist/openresponses-http-D2SenRnn.js:725-731.
• Gate AcpDispatchTailAfterReset at dist/dispatch-gfPCX7Ws.js:819 to skip auto-LLM-invocation when no user prompt is present.
• Ensure hasPromptSubmissionContent at dist/selection-D9uTvvsw.js:7470-7483 is reached on the auto-fire code path — either the auto-fire is bypassing the V2 lifecycle, or the guard's gating condition (!promptSubmission.runtimeOnly && ...) is permitting empty submissions through the runtimeOnly branch at :7600.

Architecturally adjacent (separate observation, may warrant a sibling issue): even with the 400 suppressed via workaround 1, agents have no recall of prior conversational context post-/reset. memory-qdrant plugin v1.0.15 autoRecall listens to before_agent_start (cited at ~/.openclaw/extensions/memory-qdrant/index.js:613-633), embeds event.prompt, and queries Qdrant — but on bare /reset event.prompt is the generic reset preamble, which doesn't semantically match stored memories. None of dist/startup-context-Bav4SIwP.js, dist/session-reset-service-GWn5mWEv.js, or dist/bundled/session-memory/handler.js invoke memory-qdrant memory_search on /reset (full files inspected). So there's no purpose-built reset-bootstrap recall path in v2026.4.26. Three candidate architectural fixes:

• memory-qdrant listens to before_reset / session_start and runs a fixed-shape bootstrap query
• startupContext gains a memory-search phase with fixed bootstrap queries
• before_agent_start receives a richer prompt on bare reset that includes identity/continuity query text

We would file the architectural observation as a separate issue if maintainers prefer.

Forensic artifacts available privately on request:

• Vector consult JSON captures from 5 source-grounded chain-trace consults (verbatim model responses with file:line citations)
• Per-host journal captures at the failure timestamps with full bracketing context
• Empirical reproduction traces showing reload signatures, sha256 PRE/POST per workaround attempt
• Per-host openclaw.json backups documenting the workaround state on 4 hosts and the rollback path
• Memory-bank entries documenting the diagnostic-chain methodology (8 entries total)

These are not attached because they may contain federation auth tokens, environment-specific paths, and host-specific operational state. Happy to share scrubbed extracts if helpful.

Reported by an OpenClaw federation operator running v2026.4.26 across 4 hosts.