Agent active\chat signal but hangs? | Friends of the Crustacean 🦞🤝 | Page 1

stray adder Apr 29, 2026, 9:57 PM

#

I am busy with an agent and I have many circumstances where on the openclaw control chat page is seems like the agent is still working... 3 points is lighting up... like its typing, but nothing happens.. I can wait long time... /stop does not stop it. only thing is a gateway restart.. I am using version 2026.4.22

finite orchidBOT Apr 29, 2026, 9:57 PM

#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

granite atlasBOT Apr 29, 2026, 9:59 PM

#

That sounds like a known “stale active run / abort not reaching the real run” class of bug, and 2026.4.22 is old enough that I’d update before deep-diving.

Try:

openclaw update
openclaw gateway restart
openclaw doctor

Then if it happens again, capture this while it’s stuck:

openclaw status --all
openclaw gateway status
openclaw logs --follow

#

Also try sending a standalone:

stop

or

abort

not only /stop — the docs list both Control UI Stop and out-of-band abort phrases for stuck runs. (docs.openclaw.ai)

Reason I’m leaning update-first: releases after 2026.4.22 include multiple fixes around Control UI/chat aborts, stuck waiting state, and Gateway chat run registration. If it still reproduces after updating, please file a GitHub issue with the stuck status --all + relevant logs: https://github.com/openclaw/openclaw/issues

OpenClaw

FAQ - OpenClaw

stray adder Apr 29, 2026, 10:00 PM

#

I do not want to update, from version 23 and up I have a bug that cause gateway to use 100% cpu

granite atlasBOT Apr 29, 2026, 10:00 PM

#

Fair — don’t update into a worse 100% CPU problem.

But then the bad news is: on 2026.4.22, this exact “Control UI shows active/typing, /stop can’t find/kill the run, only gateway restart clears it” is likely one of the bugs fixed in later releases. There may not be a clean workaround on .22.

What I’d do next:

openclaw status --all
openclaw tasks list --status running
openclaw logs --follow

Run those while it is stuck, before restarting. In the Control UI also try the actual Stop button and standalone messages:

stop

#

stop run
please stop

If those don’t clear it, try:

/new

or:

/reset

#

If even that queues behind the stuck run, restart is probably the only local recovery on .22.

For the CPU issue on 2026.4.23+, that’s worth filing separately with a stuck/high-CPU capture:

openclaw status --all
openclaw gateway status
openclaw logs --follow

Issue tracker: https://github.com/openclaw/openclaw/issues

I’d mention both facts in the issue: .22 hangs and cannot abort; .23+ causes 100% gateway CPU for you. That makes it much easier for maintainers to decide whether a backport/hotfix path is needed.

stray adder Apr 29, 2026, 10:04 PM

#

│ marcus (Marcus (Developer)) │ ABSENT │ 2 │ 11m ago │ ~/.openclaw/agents/marcus/sessions/sessions.json

stop

Click to react
🦞
Click to react
💯
Click to react
Add Reaction
Reply
Forward
More
[0:00]Thursday, April 30, 2026 0:00
stop run
please stop

If those don’t clear it, try:

/new

or:

/reset

#

stop
stop run
please stop
/new
/reset

all go to the queue

granite atlasBOT Apr 29, 2026, 10:05 PM

#

That ABSENT line is good — it means BOOTSTRAP.md is absent, not that the agent is absent.

So this row only tells us:

agent: marcus
bootstrap file: absent ✅
sessions: 2
last session activity: 11m ago
session store path: ~/.openclaw/agents/marcus/sessions/sessions.json

It doesn’t show whether a run is actually stuck. Next useful check while the dots are stuck:

openclaw tasks list --status running
openclaw tasks audit
openclaw logs --follow

#

Also: send stop, stop run, /new, /reset inside the same OpenClaw Control chat/session, not here in Discord.

If tasks list --status running shows nothing while Control UI still shows dots, it’s probably stale Control UI/run state on 2026.4.22. Try a browser refresh first; if still stuck, gateway restart may be the only workaround on that version.

Docs: https://docs.openclaw.ai/help/faq

#

Yep — if /stop, /new, /reset all queue, then the chat-command path is blocked behind the stuck lane.

Try the direct Gateway RPC path instead; it should bypass the chat queue:

openclaw sessions --agent marcus

Copy the relevant session key, then run:

openclaw gateway call sessions.abort --params '{"key":"PASTE_SESSION_KEY_HERE"}'

If that doesn’t work, try the lower-level abort too:

#

openclaw gateway call chat.abort --params '{"sessionKey":"PASTE_SESSION_KEY_HERE"}'

If it returns aborted, refresh the Control UI.
If it returns no-active-run but the UI still shows dots / queued messages, that’s stale run state in 2026.4.22; gateway restart is probably the only safe recovery on that version.

Docs for the RPC helper: https://docs.openclaw.ai/cli/gateway

stray adder Apr 29, 2026, 10:07 PM

#

marcus direct agent:marcus:main 9m ago MiniMax-M2.7 110k/200k (55%) verbose:on trace:off system id:25a27eb2-2496-4219-a576-d9a7a37295fa

does verbose show what is happening?

granite atlasBOT Apr 29, 2026, 10:07 PM

#

Partly, yes — verbose:on gives extra visibility for future/live agent output: tool chatter, queue notices, and more detailed failure summaries.

But in this case, since /stop, /new, and /reset are all queueing, verbose probably won’t help much. The run/lane is already wedged ahead of the command path.

Since your key is:

agent:marcus:main

try the direct abort:

openclaw gateway call sessions.abort --params '{"key":"agent:marcus:main"}'

If needed:

#

openclaw gateway call chat.abort --params '{"sessionKey":"agent:marcus:main"}'

Then refresh Control UI.

For “what is it doing?”, use logs, not verbose:

openclaw logs --follow

trace:on is more plugin-debug-specific and can be noisy/sensitive; I’d only enable it for a short repro, not normal use.

stray adder Apr 29, 2026, 10:09 PM

#

22:08:43+00:00 warn agent/embedded {"subsystem":"agent/embedded"} {"event":"embedded_run_agent_end","tags":["error_handling","lifecycle","agent_end","assistant_error"],"runId":"9301020d-4eaf-410a-8312-42a845ee0eec","isError":true,"error":"terminated","failoverReason":null,"model":"MiniMax-M2.7","provider":"minimax","rawErrorPreview":"terminated","rawErrorHash":"sha256:e8c95a2a7271","providerRuntimeFailureKind":"unknown"} embedded run agent end
22:09:03+00:00 warn agent/embedded {"subsystem":"agent/embedded"} {"event":"embedded_run_agent_end","tags":["error_handling","lifecycle","agent_end","assistant_error"],"runId":"9301020d-4eaf-410a-8312-42a845ee0eec","isError":true,"error":"terminated","failoverReason":null,"model":"MiniMax-M2.7","provider":"minimax","rawErrorPreview":"terminated","rawErrorHash":"sha256:e8c95a2a7271","providerRuntimeFailureKind":"unknown"} embedded run agent end

granite atlasBOT Apr 29, 2026, 10:10 PM

#

That log is useful. It says the embedded run is ending with an error:

error: "terminated"
model: "MiniMax-M2.7"
provider: "minimax"
runId: "9301020d-4eaf-410a-8312-42a845ee0eec"

So this is likely not “still thinking” — the model/runtime is terminating, but 2026.4.22 is not clearing the Control UI / session lane correctly.

Try aborting that exact run id:

openclaw gateway call sessions.abort --params '{"key":"agent:marcus:main","runId":"9301020d-4eaf-410a-8312-42a845ee0eec"}'

#

If that fails:

openclaw gateway call chat.abort --params '{"sessionKey":"agent:marcus:main","runId":"9301020d-4eaf-410a-8312-42a845ee0eec"}'

If it says no-active-run but Control UI still queues everything, then the run is already dead and only stale state remains — restart is probably the only recovery on .22.

After recovery, I’d switch this session away from MiniMax or compact/start fresh. The session is already at 110k/200k, and repeated terminated often points to provider/runtime instability rather than useful agent work.

stray adder Apr 29, 2026, 10:10 PM

#

does not clear, I needed to restart gateway

granite atlasBOT Apr 29, 2026, 10:11 PM

#

Yeah — that confirms it: on 2026.4.22, the run is dead, but the session/Control UI lane stays wedged. Direct abort not clearing it means gateway restart is the only recovery path on that version.

After restart, I’d do two things:

Start fresh / compact before continuing
```
/new
```
or switch away from MiniMax for this agent if you can. The log showed MiniMax-M2.7 ending with terminated.
Capture diagnostics for the bug report
```
openclaw gateway diagnostics export --output openclaw-stuck-run.zip --log-lines 5000
```
Review before sharing, then file it here: https://github.com/openclaw/openclaw/issues

Mention:

#

2026.4.22
session key agent:marcus:main
run id 9301020d-4eaf-410a-8312-42a845ee0eec
abort RPC didn’t clear it
.23+ causes 100% CPU for you, blocking update

That last part is important — otherwise the answer will just be “update,” but you can’t safely do that yet.

stray adder Apr 29, 2026, 10:11 PM

#

I asked it if it finished what it started and said no, now It doing it again and again same error is the log:

22:09:59+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ logs.tail 68ms conn=af78781c…d071 id=f814c637…67db
22:10:30+00:00 warn agent/embedded {"subsystem":"agent/embedded"} {"event":"embedded_run_agent_end","tags":["error_handling","lifecycle","agent_end","assistant_error"],"runId":"9301020d-4eaf-410a-8312-42a845ee0eec","isError":true,"error":"terminated","failoverReason":null,"model":"MiniMax-M2.7","provider":"minimax","rawErrorPreview":"terminated","rawErrorHash":"sha256:e8c95a2a7271","providerRuntimeFailureKind":"unknown"} embedded run agent end
22:10:51+00:00 warn agent/embedded {"subsystem":"agent/embedded"} {"event":"embedded_run_agent_end","tags":["error_handling","lifecycle","agent_end","assistant_error"],"runId":"9301020d-4eaf-410a-8312-42a845ee0eec","isError":true,"error":"terminated","failoverReason":null,"model":"MiniMax-M2.7","provider":"minimax","rawErrorPreview":"terminated","rawErrorHash":"sha256:e8c95a2a7271","providerRuntimeFailureKind":"unknown"} embedded run agent end
22:11:29+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ logs.tail 108ms conn=af9d0464…4fc3 id=cca239d7…91d5

granite atlasBOT Apr 29, 2026, 10:12 PM

#

Same runId repeating confirms it’s replaying/cleaning up the same failed run, not making progress.

Don’t ask it to continue in that session right now. After gateway restart, immediately do a direct session reset before sending normal chat:

openclaw gateway call sessions.reset --params '{"key":"agent:marcus:main","reason":"new"}'

Then refresh Control UI and switch away from MiniMax-M2.7 for that session if you have another configured model. This error is the model/runtime terminating repeatedly:

error: "terminated"
provider: "minimax"
model: "MiniMax-M2.7"

If you need to preserve the work, start a fresh session and give it a short manual summary of what was already done, instead of asking the wedged session “did you finish?”

#Agent active\chat signal but hangs?