openclaw - 💡(How to fix) Fix [BUG] message send CLI can hang as openclaw-message at ~100% CPU after plugin load failure [1 comments, 2 participants]

Summary

On OpenClaw 2026.4.29, openclaw message send can spawn a child process titled openclaw-message that gets stuck at ~100% CPU instead of exiting after a Telegram plugin load failure. While that process is spinning, the gateway becomes unhealthy (very large event-loop delays, Telegram replies stall, user sees something went wrong).

Environment

• OpenClaw: 2026.4.29 (a448042)
• Host: Linux
• Channel affected: Telegram
• Observed after upgrading from 2026.4.27

What happened

A monitoring script invoked:

openclaw message send --channel telegram --account ops --target telegram:5282457901 --message "[ops][session-monitor][critical] Stuck run: coder session stopped progressing"

That produced this process tree:

node openclaw message send ...   (parent)
└── openclaw                     (child)
    └── openclaw-message         (child, stuck)

Observed stuck process:

• process title: openclaw-message
• CPU: ~97%
• RSS: ~858 MB
• elapsed: ~1h44m until manually killed

While it was spinning:

• gateway event-loop delay warnings climbed as high as ~204s
• Telegram main-session replies stalled / timed out
• Telegram user-facing symptom was something went wrong

Killing the stuck openclaw-message process immediately relieved CPU pressure and restored normal behavior.

Relevant logs

Around the time the stuck process started, logs showed bundled runtime deps being staged/installed, then channel load failures:

[plugins] telegram installed bundled runtime deps in 145ms: ... grammy@^1.42.0 ...
[channels] failed to load bundled channel telegram: Cannot find module 'grammy'
Require stack:
- /home/admin/.npm-global/lib/node_modules/openclaw/dist/extensions/telegram/send-t4GTTdHF.js

There were similar failures for other bundled channels in the same CLI process:

• discord-api-types/v10
• nostr-tools
• @slack/web-api
• grammy

At the same time, the running gateway itself had already successfully brought Telegram up and was polling, so this appears specific to the separate CLI message send path / child process, not a generic gateway inability to use Telegram.

Suspected root cause

This looks like two bugs interacting:

1. Bundled runtime deps / module-path race or ordering bug in the CLI child process

   • grammy exists under the staged plugin runtime deps root: ~/.openclaw/plugin-runtime-deps/openclaw-2026.4.29-.../node_modules/grammy
   • but the CLI child still attempts to load Telegram before the runtime dep node path is effectively usable in that child process.

2. Failure path does not terminate the CLI child process cleanly

   • plugin load failures are recorded and later surfaced via PluginLoadFailureError
   • the command should exit with non-zero
   • instead, the child remains alive as openclaw-message and spins at very high CPU

I traced the relevant compiled flow as:

• dist/program-BrS1V7cf.js
  • setProcessTitleForCommand() sets process.title = "openclaw-message" for message command
• dist/register.message-BUA5UmMq.js
  • message command calls ensurePluginRegistryLoaded(...)
• dist/runtime-registry-loader-DW8FE8ql.js
  • loads plugins with throwOnLoadError: true
• dist/loader-CLyHx60E.js
  • plugin import failures are first recorded via recordPluginError(...)
  • later maybeThrowOnPluginLoadError(...) throws PluginLoadFailureError
• command does not terminate cleanly after that failure and the process stays alive spinning

Why this matters

A single failed openclaw message send invocation can consume nearly a full core plus ~858 MB RSS for a long time and indirectly break normal Telegram agent replies on small hosts.

Repro hints

I do not yet have a minimal deterministic repro outside this affected host, but the failure was observed immediately after upgrading to 2026.4.29 and invoking openclaw message send from a monitoring script on a host with Telegram configured.

Requested fix

• ensure CLI message send children either:
  • correctly register bundled runtime dep node paths before importing channel modules, or
  • fail fast and exit cleanly on plugin load failure
• in particular, avoid any path where openclaw-message can remain alive spinning after a plugin/module load error

If useful, I can provide additional logs / timestamps from the affected host.