PR #73371: fix(commands): stop bare /reset and /new from falling through to empty model call

• Repository: openclaw/openclaw
• Author: wenxu007
• State: closed | merged: False
• Link: https://github.com/openclaw/openclaw/pull/73371

Description (problem / solution / changelog)

Summary

• Problem: a bare /reset (or /new) sent to a non-ACP session resets the session, then the command handler returns null, letting normal command processing continue with an empty body. With the OpenAI Responses API the resulting model call is rejected with One of "input" or "previous_response_id" or "prompt" or "conversation_id" must be provided instead of a reset acknowledgement.
• Why it matters: every bare /reset against an OpenAI Responses-backed agent surfaces a provider error to the user instead of a clean acknowledgement.
• What changed: in src/auto-reply/reply/commands-reset.ts, the non-ACP branch now mirrors the ACP branch — when resetTail is empty, return { shouldContinue: false, reply: { text: "✅ Session reset." | "✅ New session started." } } after the reset hooks fire. When a tail is present (e.g. /new take notes), we still return null so the existing tail-dispatch behaviour is unchanged.
• What did NOT change (scope boundary): no changes to ACP path, soft-reset path, hook payloads, authorization checks, session-clearing logic, or session-store side effects. No new env vars/config keys.

Change Type

• Bug fix

Scope

• Gateway (auto-reply command handling)

Linked Issue/PR

• Closes #73367
• This PR fixes a bug or regression

Root Cause

• Root cause: maybeHandleResetCommand in src/auto-reply/reply/commands-reset.ts ended its non-ACP branch with await emitResetCommandHooks(...); return null;. The reset hooks normalize the body, so when the user sent only /reset the subsequent command-pipeline stages saw an empty body and forwarded it to the model.
• Missing detection: there was no guard for "reset hook ran AND tail is empty" in the non-ACP branch, even though the ACP branch already handled the same case (resetTail empty → reply with ✅ ACP session reset in place.).
• Contributing context: the OpenAI Responses API surfaces the empty-input case as a hard error, making the latent bug user-visible on Responses-backed providers.

Regression Test Plan

• Coverage level that should have caught this:
  • Unit test
• Target test or file: src/auto-reply/reply/commands-reset-hooks.test.ts
• Scenarios the test locks in:
  • /reset → returns { shouldContinue: false, reply: { text: "✅ Session reset." } } and still emits the reset hook.
  • /new → returns { shouldContinue: false, reply: { text: "✅ New session started." } } and still emits the new hook.
  • /new take notes → continues to return null so the tail can dispatch to the model.
• Why this is the smallest reliable guardrail: the bug is a single missing branch in maybeHandleResetCommand. The new tests pin both the empty-tail acknowledgement and the non-regression for the tail-dispatch path; the rest of the reset machinery is already covered by adjacent tests in the same file.

User-visible / Behavior Changes

• Bare /reset now replies with ✅ Session reset. instead of producing a provider error or empty turn.
• Bare /new now replies with ✅ New session started.
• /reset <tail> and /new <tail> are unchanged — the tail still dispatches to the model.

Security Impact

• New permissions/capabilities? No
• Secrets/tokens handling changed? No
• New/changed network calls? No (this PR removes an empty/erroneous provider call)
• Command/tool execution surface changed? No
• Data access scope changed? No

Repro + Verification

Environment

• OpenAI Responses-backed agent (any provider that hits One of "input" / "previous_response_id" / "prompt" / "conversation_id" must be provided)

Steps

1. Configure an agent on the OpenAI Responses API.
2. Send a bare /reset to that agent on a non-ACP channel (e.g. WhatsApp/Telegram/webchat).

Expected

• Reset hook fires, then a clean acknowledgement reply is delivered. No provider call.

Actual (before fix)

• Reset hook fires; command pipeline continues with empty body; provider rejects the request and the error surfaces to the user.

Evidence

• Static reproduction is provided by the new unit tests in src/auto-reply/reply/commands-reset-hooks.test.ts. The fix mirrors the existing ACP-path behaviour at the top of maybeHandleResetCommand.

Human Verification

• Verified scenarios: TypeScript clean on touched files; new tests added next to existing reset-hooks suite.
• Edge cases checked: bare /reset, bare /new, /new <tail> (must still fall through), ACP path (untouched), soft-reset path (untouched).
• What I did NOT verify: a live end-to-end run against a Responses-backed provider; full pnpm check / pnpm test was not exercised locally, leaving CI as the verification surface.

Compatibility / Migration

• Backward compatible? Yes
• Config/env changes? No
• Migration needed? No

Risks and Mitigations

• Risk: a downstream consumer relied on null being returned for bare /reset to trigger some additional pipeline step.
  • Mitigation: this matches the established ACP-path behaviour for the same input; bare /reset was already broken on the OpenAI Responses path, so the previous behaviour was not a load-bearing contract.

Changed files

• CHANGELOG.md (modified, +1/-0)
• src/auto-reply/reply/commands-reset-hooks.test.ts (modified, +48/-0)
• src/auto-reply/reply/commands-reset.ts (modified, +16/-0)

---

PR #73377: fix(reply): short-circuit bare /reset and /new instead of calling provider with empty input

• Repository: openclaw/openclaw
• Author: Sanjays2402
• State: closed | merged: False
• Link: https://github.com/openclaw/openclaw/pull/73377

Description (problem / solution / changelog)

What

When a user sends a bare /reset or /new (no trailing text) on a non-ACP-bound channel, maybeHandleResetCommand emits the reset hooks and returns null, which lets the rest of the auto-reply pipeline continue and call the model provider with an empty body. The OpenAI Responses‑compatible API surfaces this as:

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

…instead of the user getting a reset acknowledgement.

Fix

After running the reset hooks, if resetTail is empty, stop the pipeline and reply with a plain ack:

• /reset → ✅ Session reset.
• /new → ✅ New session started.

/reset <message> and /new <message> are unchanged — they still fall through and seed the next turn with the tail, matching the existing intent.

This mirrors the existing behaviour on the ACP-bound branch above (which already returns an explicit ack when resetTail is empty).

Diff

src/auto-reply/reply/commands-reset.ts — 8 lines added at the bottom of maybeHandleResetCommand, no other changes.

Fixes #73367

Changed files

• src/auto-reply/reply/commands-reset.ts (modified, +8/-0)