OpenClaw Feishu Bug: /stop and /new May Not Interrupt a Running Session (v2026.3.23)

A newly reported Feishu channel bug means /stop and /new may appear to work in the UI but fail to interrupt the running agent turn.

In other words:

• Feishu accepts the command
• no obvious error is shown
• but the active task keeps running until it finishes naturally

Source:

• Issue report: openclaw/openclaw#54151

What the issue says

The report targets OpenClaw 2026.3.23 on a Feishu direct-message setup.

Observed behavior:

• Start a long-running task
• send /stop or /new while it is still processing
• the system appears to acknowledge the command
• but the agent still completes the original run and returns a response

Expected behavior:

• /stop should interrupt the active run
• /new should clear the current thread / abort the active turn the same way it does on other channels

Why this matters

This is not just a cosmetic bug.

If your team uses Feishu as an operations or research console, a broken stop path creates three immediate risks:

1. Wasted time

   • operators assume the run was canceled, but it is still consuming time and tool calls.

2. Higher cost / unintended side effects

   • long tasks may continue reading files, hitting APIs, or generating content after the operator tried to halt them.

3. Workflow confusion

   • the chat state suggests the command was accepted, so people may trigger duplicate retries or start a second instruction too early.

How to confirm you are hitting the same bug

You are likely seeing the same regression if all of the following are true:

• channel = Feishu
• OpenClaw version is near 2026.3.23
• the failing commands are /stop and/or /new
• the active run continues even after the command is sent

A quick test loop:

1. Trigger a task that reliably takes 20–60 seconds.
2. While the agent is still working, send /stop.
3. If the run still returns a full answer, the stop signal likely did not reach the execution layer.
4. Repeat with /new.

If the same commands work correctly on another channel (for example Discord or Telegram) but not in Feishu, that is an even stronger signal that this is channel-specific.

Practical mitigation until a fix lands

1) Avoid using Feishu as the only control surface for long runs

If you have another channel where interruption works correctly, use that channel for:

• large research jobs
• code tasks
• workflows that call external services

2) Prefer smaller, chunked requests

Instead of one large request, split the work into short steps. That lowers the damage when a stop command fails.

For example, prefer:

• “Summarize the repo structure first”
• then “Now inspect the latest 3 commits”

instead of asking for a full multi-stage audit in one shot.

3) Warn operators that the chat acknowledgment may be misleading

If multiple people use the same Feishu bot, document this clearly:

• /stop shown ≠ run actually stopped
• wait for the final agent output before assuming the turn is dead

4) Capture logs before retrying repeatedly

If you operate the gateway yourself, gather the exact timestamps and related logs around:

• long task start
• /stop or /new message arrival
• final completion of the task

That evidence is more useful than repeatedly re-running the same scenario.

Who is most affected by this Feishu stop bug

This issue matters most for three groups:

• Operators using Feishu as the main control surface, because they may assume a long run is dead when it is still active.
• Teams with tool-heavy agent workflows, where a failed stop can keep burning API calls, file reads, and debugging time.
• Anyone coordinating multiple humans around one bot, because a false sense of cancellation often creates duplicate retries and conflicting instructions.

Common containment questions

When should you stop retrying /stop and switch to blast-radius reduction

If the UI already acknowledged the command once and the active run still keeps producing output, repeated /stop attempts are less useful than reducing damage: stop issuing new instructions, move follow-up work to another channel, and record timestamps for logs.

Is /new safer than /stop in this bug shape

Not necessarily. If both commands are accepted at the chat layer but neither interrupts the active run, switching between /new and /stop may change the interface state without solving the underlying execution-control problem.

What maintainers will likely need to inspect

Based on the current report, the most useful places to inspect are likely:

• Feishu command parsing for slash-style commands
• channel-to-session routing for interruption events
• whether the cancel / reset intent is acknowledged in chat but never propagated to the active run controller

That is a technical hypothesis, not a confirmed root cause.

Search-intent checklist: what users usually mean when they search this problem

Most operators will not search for the full issue title.

They usually search the symptom they just saw, for example:

• OpenClaw Feishu /stop not working
• OpenClaw /new not stopping current task
• Feishu slash command accepted but agent keeps running
• OpenClaw Feishu cannot interrupt running session
• Feishu /stop acknowledged but task still finishes

If you landed here from one of those searches, use this shortest decision tree:

1. If the command is not recognized at all
   • this is more likely a command parsing or channel formatting problem than the exact bug described here.
2. If the command is acknowledged but the old task still returns a full answer
   • this is the strongest match for the Feishu interruption failure pattern.
3. If /stop fails only on Feishu but works on another channel
   • prioritize channel-specific interruption routing, not general session logic.
4. If the run was already finished before you sent /stop
   • that is operator timing, not this regression.

That symptom-first framing is usually faster than reading raw logs from scratch.

When this article is probably NOT your problem

This page is likely the wrong match if:

• the command never appears in chat at all
• Feishu cannot send any slash-style command, not just /stop or /new
• the run actually stops, but a delayed old message arrives from a separate queue or webhook retry
• the same failure happens identically on every other channel you use

In those cases, start with command formatting, delivery/routing, or broader session-control regressions before assuming you hit this specific Feishu bug shape.

3-step operator summary

If you only have two minutes, do this in order:

1. start a 20–60 second task in Feishu
2. send /stop or /new before it completes
3. verify whether the original run still returns a full answer

If step 3 is yes, you likely hit the same regression pattern. If the same test works on another channel, treat Feishu routing as the leading suspect.

Adjacent searches that usually come with this problem

If you landed here from search, you are often also looking for nearby questions like:

• Does Feishu /stop fail more often than /new
• How to safely limit blast radius for long OpenClaw tasks in Feishu
• Do Feishu DMs and group chats interrupt differently
• Which gateway logs matter after a stop command is acknowledged

For most operators, the first useful question is not whether this is a brand-new bug. It is: is a long task still consuming time, tool calls, and attention after you thought it was canceled?

A practical decision order is:

1. confirm whether the task is still producing output
2. verify whether both /stop and /new fail in Feishu
3. compare the same behavior on another channel
4. only then package the issue report and logs

Fast triage: when is this more likely a Feishu-channel failure vs a broader session-control failure

If you want the quickest routing decision before digging into code, use this split:

• Only Feishu fails while other channels interrupt correctly
  • prioritize Feishu-side command parsing, routing, or cancellation delivery.
• Every channel fails to stop active runs
  • treat it as a broader session / run control problem, not a Feishu-only regression.
• /new fails but /stop sometimes still works
  • that suggests reset/new and stop may not share the exact same control path, so they should be logged separately.
• The chat says the command was accepted, but the final result still lands in the same thread
  • that is the highest-value failure shape to capture, because it shows the problem is less about message delivery and more about whether cancel intent actually reached the execution layer.

This kind of triage helps operators decide within a few minutes whether to switch channels for containment or continue digging into underlying run control.

Five-minute containment checklist when Feishu interruption fails

If you are in the incident right now, do not spend the whole window repeatedly sending /stop. Contain the run first, then collect evidence.

1. Stop adding new instructions in the same Feishu thread so old and new outputs do not mix.
2. Move follow-up control to a channel with known-good interruption, such as Web, Telegram, Discord, or local CLI.
3. Record three timestamps: task start, /stop or /new send time, and final old-task completion time.
4. If the run uses tools, pause high-cost or high-risk tool paths before the background work expands the blast radius.
5. After the task ends or another control surface confirms cancellation, package logs and reproduction steps.

The point is not to prove the bug immediately. It is to prevent a Feishu control failure from turning a small interruption bug into a long-running cost and operations problem. For on-call readers arriving from search, contain first, then diagnose.

What to include in a high-quality bug follow-up

If you want the issue fixed faster, include:

• OpenClaw version
• Feishu setup type (DM / group)
• whether the active task was model-only or tool-heavy
• exact command sent (/stop or /new)
• whether the UI acknowledged the command
• whether the final original answer still arrived
• any relevant gateway logs around the same timestamps

What high-intent questions should this page answer more directly

Pages like this win search traffic when they answer the operator's next decision, not just restate the issue title.

The most useful high-intent questions to answer directly are:

• Should I keep retrying in Feishu, or switch control to another channel now?
  • If the long task is still producing output, moving control to a channel with known-good interruption is usually safer than hoping /stop suddenly starts working.
• Does this look Feishu-specific, or is the broader OpenClaw stop path broken everywhere?
  • If Discord, Telegram, or another channel can still interrupt correctly while only Feishu fails, this is much more likely a channel-specific regression.
• What evidence should I collect first so maintainers can localize it faster?
  • The highest-value evidence is usually task start time, /stop send time, final completion time, and the matching gateway logs.

Which search queries should this page answer directly

To capture more high-intent traffic, this page should answer searches like:

• openclaw feishu stop not working
• openclaw /new not stopping current task
• feishu slash command accepted but agent keeps running
• openclaw feishu cannot interrupt running session
• feishu /stop acknowledged but task still finishes

Those searches all come from the same place: the operator is not reading bug news, they are looking for the fastest containment move.

If you arrived from Kimi reset, release evaluation, or safety/cost pages

Those entry paths often bring readers who already feel that the conversation is “out of control,” but the control-path failure may be different. Split it this way first:

• A normal user message immediately shows a /new or /reset lifecycle banner: that is a better match for the Kimi-Claw forced reset issue, where session lifecycle may be recreated accidentally.
• The same thread keeps running, but /stop or /new fails to interrupt it: that is closer to this Feishu interrupt event failing to reach the execution layer.
• You noticed the behavior after an upgrade, migration, or cost spike: check the 2026.3.13 release evaluation, migration guide, and safety/cost page before treating it as Feishu-specific.

This routing keeps “session was reset,” “run will not stop,” “post-upgrade instability,” and “tool calls keep burning cost” in separate buckets. This page is the right mitigation path only after you confirm Feishu accepted the command but the execution layer did not stop.

If troubleshooting traffic lands here, separate command delivery from session cancellation

GA4 now shows this Feishu stop-command page next to setup and agent troubleshooting entries. Readers may arrive after typing /stop, but the useful diagnosis depends on where the interrupt was lost.

Split the incident before restarting the bot:

1. Feishu never delivered the command: check callback verification, bot permissions, chat type, and whether the message event reached OpenClaw logs.
2. OpenClaw received /stop but the session kept running: capture the session id, active task type, runtime adapter, and whether cancellation hooks fired.
3. A new command starts while the old run still writes output: treat it as a concurrency or channel routing issue, not a Feishu auth problem.

This keeps high-intent troubleshooting readers from reinstalling the Feishu app when the real fix is in session cancellation or channel event routing.

If an expensive run will not stop, apply this five-minute guardrail first

When Feishu has accepted /stop but the old run keeps calling tools or writing output, the first goal is not proving the bug. It is shrinking the blast radius:

1. Pause external side effects immediately: if the task can send messages, write documents, deploy, or call paid APIs, pause tokens, hooks, or queue entrypoints from the platform side first.
2. Switch the control surface: use Web, CLI, or another channel with known-good interruption to check whether the same session can still be controlled.
3. Freeze new instructions: do not keep adding complex commands in the same Feishu thread, because the old run and new run may interleave output.
4. Record the cost window: note the minutes between /stop and actual old-run completion, the number of tool calls, and any external writes.
5. Write the recovery conclusion: after restoration, state whether this was lost Feishu interrupt delivery, global cancellation failure, or tools ignoring cancellation signals.

This guardrail helps readers arriving from safety/cost, release-incident, or homepage paths. It turns “why will this not stop” into “how do we stop the impact from expanding,” which matches real on-call priority.

Copy these six Feishu stop lines into the incident ticket

If the failed /stop affected cost, external writes, or customer-facing chat, capture evidence in a fixed six-line ticket instead of relying on screenshots:

Feishu stop incident:
- session / thread: <session id, chat type, channel>
- task start / stop sent / actual finish: <timestamps>
- command path: </stop or /new, acknowledged or not>
- blast radius: <tool calls, writes, paid API usage, messages sent>
- cross-channel check: <Web/CLI/other channel can stop or cannot stop>
- owner decision: <pause token, disable hook, rollback, or escalate>

Those six lines help maintainers decide whether the fault sits in the Feishu channel, global cancellation, or tool-level cancellation handling. They also give the team a clean cost-impact window for the postmortem.

Decide whether to disable Feishu writes or wait for the run to drain

When /stop fails during a costly Feishu run, the next decision is operational rather than editorial: should you keep the channel online, or temporarily block writes until the old run finishes?

Use this split:

1. Disable writes immediately if the run can message customers, edit shared documents, deploy code, or spend paid API budget without another human confirmation.
2. Let the run drain under observation if it is read-only, already near completion, and cross-channel control still works from Web or CLI.
3. Escalate as a platform incident if new Feishu messages start additional runs while the old one continues, because that points to concurrency and routing risk rather than a single stuck task.

This gives search visitors a concrete cost-control decision before they collect logs. The page should not only explain why Feishu /stop failed; it should help operators decide when to pause the channel to prevent more damage.

Confirm whether stop failed in Feishu routing or agent cancellation

When a Feishu user says “stop does not work,” split the incident before changing command aliases or restarting the gateway:

1. Message routing: confirm the Feishu event containing stop reached OpenClaw and was mapped to the same conversation/session that is running the task.
2. Command parsing: check whether the channel treated stop as plain text, a reply, an at-mention command, or a slash-style command, because each path may hit a different handler.
3. Cancellation boundary: verify whether the agent process received a cancellation signal, whether only the chat stream stopped, or whether the background task kept running.
4. User-facing fallback: if cancellation cannot be guaranteed, reply with the session id and the safest manual kill or steering path instead of pretending the task stopped.

This keeps Feishu stop-command traffic actionable: routing bug first, parser mismatch second, cancellation/runtime bug third.

Turn stop-command traffic into cancellation-path triage

If you arrived because /stop does not work in the Feishu channel, do not judge the issue only by whether the agent keeps printing. Split the cancellation path into four segments: whether Gateway received the Feishu message, whether command parsing matched the active session, whether the running agent received the cancel signal, and whether the channel is replaying old output.

The minimal triage path is the /stop message id, target session id, process state, and the first response after stopping. Escalate it as a cancellation bug only when the command matched the session but the agent kept running. Otherwise, fix routing, permission, session binding, or duplicate delivery first.

Stop-command triage before restarting the Feishu channel

If you arrived here by searching “OpenClaw Feishu stop command not working” or “Feishu channel ignores stop”, treat the first pass as a command-routing check, not a full channel outage. Use this order:

1. confirm the message text reaches the Feishu channel handler exactly as the user sent it;
2. verify whether the stop command is parsed before or after thread/session routing;
3. check whether the active run is attached to a different session, tenant, or document context than the stop message;
4. send one controlled stop command while tailing gateway logs and the agent session state;
5. only restart the Feishu channel after you prove the command is received but not propagated to the running task.

This helps operators protect live Feishu workflows: the safest fix is to locate the broken layer between message ingestion, command parsing, session lookup, and cancellation propagation before interrupting unrelated channel traffic.

Related reading

• OpenClaw Core Schema Mismatch with the Official Feishu Plugin: Why Messages Fail and What to Check First
• Mastering Agent Swarms: A Guide to Multi-Agent Workflows in OpenClaw
• Troubleshooting OpenClaw Agents: What to Check When Tasks Stall or Tools Misbehave
• OpenClaw Complete Installation Guide: From Environment Setup to First Successful Run

FAQ for search and interrupt-path triage

If the chat already shows /stop was accepted, why can’t operators treat the task as truly stopped?

Because in this failure shape, chat-layer acknowledgment and execution-layer interruption are not the same event.

If the command is visibly accepted but the original run still produces output until completion, the safer interpretation is that the stop intent never actually reached the run controller.

When should teams suspect Feishu channel routing before blaming general session-control logic?

If the same /stop or /new works correctly on other channels and fails only on Feishu, Feishu-side parsing, routing, or cancellation delivery deserves priority.

That comparison usually narrows the blame surface much faster than staring at one failed run in isolation.

If someone searches for feishu stop acknowledged but task still running, what are the first three branches this page should help them split?

Help them separate these first:

1. whether the command was never recognized or was accepted but failed to stop the run
2. whether only Feishu fails or every channel fails to interrupt
3. whether the failure affects /stop, /new, or both

Those three checks are the fastest way to move from “why won’t this task stop” to “the Feishu interrupt event is not reaching the execution layer”.

Search-entry triage: what to check when the stop command does not work in Feishu

If you landed here from searches like “Feishu stop command not working”, “OpenClaw cannot stop task in Feishu”, or “/stop has no effect”, split the issue into four layers:

1. Check whether Feishu delivered the command as typed: inspect the message event for /stop, and whether rich text, bot menus, or quoted replies rewrote it.
2. Check whether the channel adapter treated it as a control command: if the adapter passes /stop as a normal user message, the agent will keep answering instead of cancelling.
3. Check which running task should be stopped: in multi-session, multi-thread, or subagent flows, the stop command can target the wrong session.
4. Check whether the cancel signal reached the runtime: after command parsing succeeds, verify that the task queue, tool call, or background run actually received cancel.

Do not debug this class of bug only from whether the UI says “stopped”. The shortest path is to compare four layers: Feishu event, adapter parsing, session targeting, and runtime cancellation.

Related reading

• Troubleshooting OpenClaw Agents: What to Check When Tasks Stall or Tools Misbehave
• Troubleshooting Feishu Token Configuration
• What to Check When OpenClaw Core Schema Is Incompatible with the Official Feishu Plugin
• What to Check First When sessions_send Times Out

Source

• openclaw/openclaw#54151