Issue Station
Sign In
Tools hereToolbox

openclaw - 💡(How to fix) Fix [Bug]: CLI enters CPU 100% infinite loop on unknown/unregistered subcommands (v2026.4.5) [1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#62356•Fetched 2026-04-08 03:05:32
View on GitHub
Comments
0
Participants
1
Timeline
4
Reactions
1
Author
Lori-zhangLori-zhang
Participants
Lori-zhangLori-zhang
Timeline (top)
cross-referenced ×2labeled ×2

OpenClaw CLI v2026.4.5 enters a CPU 100% infinite loop when invoking unregistered or certain subcommands (e.g. openclaw flows --help, openclaw tasks --help, openclaw sessions --help) inside a Docker container. The CLI does not report "unknown command" for unregistered subcommands — instead it hangs indefinitely, consuming 100% CPU per stuck process. Gateway HTTP API remains healthy throughout.

Error Message

For unregistered subcommands like flows: CLI should print "error: unknown command 'flows'" and exit with non-zero code, similar to how other unknown commands are handled (e.g. openclaw changelog correctly returns "error: unknown command 'changelog'").

Root Cause

OpenClaw CLI v2026.4.5 enters a CPU 100% infinite loop when invoking unregistered or certain subcommands (e.g. openclaw flows --help, openclaw tasks --help, openclaw sessions --help) inside a Docker container. The CLI does not report "unknown command" for unregistered subcommands — instead it hangs indefinitely, consuming 100% CPU per stuck process. Gateway HTTP API remains healthy throughout.

Code Example

$ docker exec openclaw openclaw --version
OpenClaw 2026.4.5

$ docker exec openclaw openclaw flows --help
# Hangs indefinitely, never returns

$ ps aux (inside container):
PID 40736: openclaw flows --help    - 99% CPU
PID 41039: openclaw tasks --help    - 99% CPU
PID 41089: openclaw sessions --help - 99% CPU

$ curl http://localhost:18789/health
{"ok":true,"status":"live"}

Note: `openclaw --help` works fine and does NOT list `flows` in its subcommand list.
`openclaw agent` subcommand works correctly.
RAW_BUFFERClick to expand / collapse

Bug type

Crash (process/app exits or hangs)

Beta release blocker

No

Summary

OpenClaw CLI v2026.4.5 enters a CPU 100% infinite loop when invoking unregistered or certain subcommands (e.g. openclaw flows --help, openclaw tasks --help, openclaw sessions --help) inside a Docker container. The CLI does not report "unknown command" for unregistered subcommands — instead it hangs indefinitely, consuming 100% CPU per stuck process. Gateway HTTP API remains healthy throughout.

Steps to reproduce

  1. Run Docker container with alpine/openclaw:2026.4.5
  2. Execute: docker exec openclaw openclaw flows --help
  3. Observe the process hangs at 100% CPU and never returns
  4. Confirm with ps aux inside container: the openclaw process is stuck at 99% CPU
  5. Same behavior with openclaw tasks --help and openclaw sessions --help
  6. Note: openclaw --help does NOT list flows as a subcommand, but CLI does not reject it
  7. Note: openclaw --version and openclaw agent --agent code --message "test" work correctly

Expected behavior

For unregistered subcommands like flows: CLI should print "error: unknown command 'flows'" and exit with non-zero code, similar to how other unknown commands are handled (e.g. openclaw changelog correctly returns "error: unknown command 'changelog'"). For registered subcommands like sessions: CLI should print help text and exit normally.

Actual behavior

CLI process enters CPU 100% infinite loop and never returns. Process snapshot shows 99% CPU usage. Multiple stuck processes accumulate and eventually make all docker exec commands unresponsive, requiring Docker Desktop restart. openclaw --help does not list flows as a subcommand, but CLI does not reject it as unknown — it silently enters the dead loop.

OpenClaw version

2026.4.5

Operating system

Windows 11 (Docker Desktop, container image alpine/openclaw:2026.4.5)

Install method

docker

Model

minimax/MiniMax-M2.7-highspeed (not relevant to this bug — CLI hangs before any model call)

Provider / routing chain

N/A — bug occurs in CLI → gateway RPC connection layer, before any provider is involved

Additional provider/model setup details

This bug is not model/provider related. The CLI subcommands (flows, tasks, sessions) hang during gateway RPC connection establishment. Gateway HTTP API at localhost:18789/health responds normally with {"ok":true,"status":"live"}. The issue is purely in CLI command routing and RPC transport.

Logs, screenshots, and evidence

$ docker exec openclaw openclaw --version
OpenClaw 2026.4.5

$ docker exec openclaw openclaw flows --help
# Hangs indefinitely, never returns

$ ps aux (inside container):
PID 40736: openclaw flows --help    - 99% CPU
PID 41039: openclaw tasks --help    - 99% CPU
PID 41089: openclaw sessions --help - 99% CPU

$ curl http://localhost:18789/health
{"ok":true,"status":"live"}

Note: `openclaw --help` works fine and does NOT list `flows` in its subcommand list.
`openclaw agent` subcommand works correctly.

Impact and severity

No response

Additional information

No response

extent analysis

TL;DR

The OpenClaw CLI enters a CPU 100% infinite loop when invoking unregistered or certain subcommands, and a workaround is to modify the CLI command routing to handle unknown subcommands correctly.

Guidance

  • Verify that the issue is specific to the openclaw CLI version 2026.4.5 and the alpine/openclaw:2026.4.5 Docker image.
  • Check the CLI code for the command routing logic to see if it can be modified to handle unknown subcommands and print an "unknown command" error message instead of entering an infinite loop.
  • Test the openclaw CLI with other subcommands to see if the issue is specific to certain subcommands or if it's a more general problem.
  • Consider modifying the Docker container to run the openclaw CLI with a different version or configuration to see if the issue persists.

Example

No code snippet is provided as the issue is related to the internal workings of the openclaw CLI and its interaction with the Docker container.

Notes

The issue seems to be specific to the openclaw CLI version 2026.4.5 and the alpine/openclaw:2026.4.5 Docker image. The Gateway HTTP API remains healthy throughout, indicating that the issue is likely related to the CLI command routing and RPC transport.

Recommendation

Apply a workaround by modifying the CLI command routing to handle unknown subcommands correctly, as the root cause of the issue is likely related to the CLI's internal logic.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

For unregistered subcommands like flows: CLI should print "error: unknown command 'flows'" and exit with non-zero code, similar to how other unknown commands are handled (e.g. openclaw changelog correctly returns "error: unknown command 'changelog'"). For registered subcommands like sessions: CLI should print help text and exit normally.

#api#agent setup#task chaining#parallel task#integration issue

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING