openclaw - 💡(How to fix) Fix Telegram /new sends empty OpenAI/Codex Responses request after reset [1 comments, 2 participants]

Summary

After updating to OpenClaw 2026.4.26, Telegram direct-chat /new no longer reliably starts a usable fresh session. A bare /new resets/creates the next session transcript, but the follow-up assistant startup/greeting run is sent to the openai-codex Responses provider without any actual input/prompt/conversation id. The provider rejects the call, and the raw provider error is sent back into Telegram.

This makes /new effectively unusable from Telegram when the default model/provider is openai-codex/gpt-5.5.

Environment

• OpenClaw package: [email protected]
• Channel: Telegram bot, direct chat
• Session key observed: agent:main:telegram:direct:<telegram-user-id>
• Provider/model: openai-codex/gpt-5.5
• Runtime: gateway service via openclaw-gateway
• Reproduced immediately after latest update on 2026-04-28 UTC

Steps to reproduce

1. Configure Telegram channel and use a Telegram direct chat bound to a normal OpenClaw assistant session.

2. Use openai-codex/gpt-5.5 as the active/default model for that session.

3. Send a bare Telegram command:

   /new

4. Observe that OpenClaw performs the reset/session-start path, then attempts an assistant run for the fresh session.

Expected behavior

• /new should reset/archive the old transcript and create a fresh transcript/session.
• The new session should either:
  • wait silently for the next user message, or
  • send a friendly startup/greeting using a real synthetic prompt/input that is valid for the selected provider.
• Raw provider/API errors should not be delivered to Telegram users.

Actual behavior

• The reset path creates a fresh session/transcript with no user content.

• The subsequent startup/greeting assistant run reaches openai-codex with an empty request payload: no input, no prompt, no conversation_id, and no previous_response_id.

• The provider rejects the call with:

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

• That raw error is then sent to Telegram instead of being sanitized.

Representative gateway log lines:

2026-04-28T17:27:12+00:00 [ws] ⇄ res ✓ sessions.reset 24214ms ...
2026-04-28T17:47:18+00:00 [agent/embedded] embedded run agent end: runId=e27e0843-1b1d-4218-9f7d-b40e52e19d51 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.
2026-04-28T17:47:20+00:00 [telegram] sendMessage ok chat=<redacted> message=<redacted>

Likely source / code path

Observed flow:

Telegram /new
  -> auto-reply command handling for /new|/reset
  -> reset hooks / internal command event
  -> gateway session reset (`sessions.reset` / session-reset-service)
  -> fresh transcript with only the session header and no user message
  -> startup/greeting assistant run
  -> openai-codex Responses provider call with empty payload
  -> provider error leaked back to Telegram

Relevant installed build files inspected locally:

• dist/commands.runtime-BBQOlJl9.js
  • maybeHandleResetCommand() matches /new|/reset and emits reset hooks for non-ACP Telegram sessions, then returns null so normal command/agent flow can continue.
• dist/session-reset-service-GWn5mWEv.js
  • performGatewaySessionReset() creates the next session entry, writes a fresh transcript header, emits session end/start hooks, and unbinds lifecycle state.

The failure appears to be in the bare /new startup path after reset: the system tries to generate an assistant response for the new empty transcript but does not inject any provider-valid startup prompt/input for openai-codex Responses.

Suggested fixes

1. Add a guard before provider calls: if the compiled request has no input, prompt, conversation_id, or previous_response_id, do not call the provider.
2. Ensure bare /new from Telegram either stops after reset with a simple channel confirmation, or injects a real startup prompt as provider input.
3. Sanitize provider errors before sending channel replies, especially for remote/messaging channels.
4. Add a regression test for bare Telegram /new with an empty command body using the openai-codex Responses provider.