Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

When typing /reset soft [message] in the OpenClaw WebChat Control UI input box, the args after /reset are silently dropped. The Control UI sends a hardcoded "/reset" string to the Gateway instead of the user's full message, causing a hard reset to run even though the user requested a soft reset. The old transcript is silently archived, with no warning to the user.
This is a regression in the Control UI dispatch path — the agent.send path, CLI, Telegram, Feishu, and other channels are not affected and correctly pass args through.

Steps to reproduce

1. Open Control UI, connect to any session that has transcript history
2. Type in the input box: /reset soft please reload system prompt
3. Press Enter
4. Observe: a globalThis.confirm("Start a new session? This will reset the current chat.") dialog appears
5. Click OK
6. Observe: the UI shows ✅ Session reset.
7. Scroll back to the previous messages — the transcript has been cleared

To verify the same command works correctly in the agent.send path or in Feishu/Telegram/CLI: send /reset soft please reload system prompt — the transcript is preserved, no confirmation dialog, soft reset runs as expected.

Expected behavior

Actual behavior

Control UI truncates "/reset soft" to "/reset" — args dropped, transcript silently wiped`,control ui can't read "/reset soft" ,if you send this on web chat,it will execute the "/reset" instead.The "/reset soft" won't show in the Control UI 's Command Auto-Completion Panel.

OpenClaw version

2026.5.7

Operating system

Windows 10

Install method

pnpm dev

Model

minimax M3

Provider / routing chain

openclaw->minimax m3

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Root cause

**File:** `ui/src/ui/app-chat.ts`
**Lines:** 567-572


case "reset":
  await sendChatMessageNow(host, "/reset", {  // ← hardcoded "/reset", args dropped
    refreshSessions: true,
    previousDraft: sendOpts?.previousDraft,
    restoreDraft: sendOpts?.restoreDraft,
  });
  return;


`parseSlashCommand` (`ui/src/ui/chat/slash-commands.ts:535`) correctly extracts `args="soft [message]"` and passes it to `dispatchSlashCommand`. But the `case "reset":` branch ignores the `args` parameter and sends a hardcoded `"/reset"` literal. The Gateway-side `parseSoftResetCommand` (`src/auto-reply/reply/commands-reset-mode.ts`) never sees the `soft` token, so it falls through to the hard reset branch.

A secondary UX issue lives in `isChatResetCommand` (`ui/src/ui/app-chat.ts:127-135`):


return normalized.startsWith("/new ") || normalized.startsWith("/reset ");


`startsWith("/reset ")` matches `/reset soft` too, so `confirmChatResetCommand` triggers the hard-reset confirmation dialog for what the user intended to be a soft reset.

Impact and severity

No response

Additional information

Suggested fix (minimal)

// app-chat.ts:567
case "reset":
  await sendChatMessageNow(host, args ? `/reset ${args}` : "/reset", {
    refreshSessions: true,
    previousDraft: sendOpts?.previousDraft,
    restoreDraft: sendOpts?.restoreDraft,
  });
  return;

// app-chat.ts:127 (isChatResetCommand)
if (normalized.startsWith("/reset soft")) {
  return false;  // soft reset is silent and in-place, no confirm needed
}