Upstream bug report DRAFT — pending Trent blind-pass

Target: github.com/openclaw/openclaw/issues Status: DRAFT v0 — not filed.

Title

openclaw infer model run hangs on 4.26; child is killed only by caller timeout

Environment

• OpenClaw 2026.4.26 (be8c246)
• Install: npm-global at /home/openclawops/.npm-global/lib/node_modules/openclaw/openclaw.mjs (despite update status reporting "pnpm")
• ExecStart: /usr/bin/node /home/openclawops/.npm-global/lib/node_modules/openclaw/openclaw.mjs gateway run --port 43127 --bind loopback
• Production Telegram lane via gateway: works fine (so model lane via gateway is alive — only CLI bare-invocation path affected)

Summary

On 4.26, openclaw infer model run --model <provider/model> --prompt '...' hangs indefinitely after invocation. The only termination is via external timeout — the parent process kills the hung child with SIGKILL. The OS does not kill the process; the kill comes from the caller's exec timeout policy.

Reproduction (on 4.26, both confirmed)

# Both forms hang on 4.26
openclaw infer model run --model openai-codex/gpt-5.5 --prompt 'Reply with exactly: smoke-ok'
openclaw infer model run --local --model openrouter/xiaomi/mimo-v2-pro --prompt 'Reply: ok'

Behavior:

• Process starts
• No model output produced
• Process does not exit on its own
• Holds resources for as long as the caller is willing to wait
• Caller's exec timeout (we used 60s+) eventually fires SIGKILL

Verified NOT the cause

Exhaustive root-cause work via VPS-internal diagnostics:

• Not kernel OOM: dmesg has zero OOM/killed entries during the hang window
• Not cgroup memory enforcement:
  • memory.events: oom 0, oom_kill 0, max 0, high 0
  • memory.max=max (uncapped)
  • service memory peak ~2.48GB
• Not systemd kill: systemctl status openclaw reports service healthy throughout, no kill/failure indication
• Not session-disk-budget enforcement: session.maintenance.mode: "warn" (no enforcement); session-disk-budget warnings firing during the same window are correlated noise, not causal
• Not the modelRun:true allowlist precheck bug (filed separately — that bug produces an immediate fatal error, not a hang; both --gateway and bare CLI exhibit the hang on 4.26)

The kill is purely the parent-process exec timeout firing on a hung child. The OpenClaw process is alive but never produces output or exits.

Production impact

LOW — production agent runs go through the Telegram/agent gateway path, which works correctly. CLI smoke gates and any user/script that invokes infer model run directly are broken. We marked our 4.26 cutover post-flight CLI smoke as failed/hung but proceeded anyway since the model lane through the gateway is unaffected.

What we tried (4.26)

• bare openclaw infer model run --model openai-codex/gpt-5.5 --prompt ... — hung
• bare openclaw infer model run --local --model openrouter/xiaomi/mimo-v2-pro --prompt ... — hung

We did not retest with --gateway on 4.26 because the bare CLI was already hanging; the prior --gateway issue on 4.25 was a separate precheck bug (filed separately). Both --gateway and bare invocations exhibit hangs on 4.26 but the underlying failure modes may differ.

Possible 4.26 contributors (from CHANGELOG inspection)

• Line 182: massive deferred init — QMD, embedded-run activity reads, plugin HTTP routes, MCP loopback, channel runtime helpers, etc. all moved to lazy/on-request. Could mean the FIRST infer model run on a fresh boot triggers a heavy lazy-init burst that deadlocks
• Line 115: session write lock acquired only after cold bootstrap, plugin, and tool setup — startup ordering change
• Line 67: live-session model switch conflicts now classified as "unknown fallback failures" — could mask the real failure mode

We don't have a confirmed root cause; this report is filed pending upstream instrumentation / strace follow-up to narrow the deadlock site.

Suggested investigation

1. Strace the hung child to identify what syscall it's blocked on
2. Add a CLI-mode init timeout that surfaces the lazy-init step that deadlocked (instead of hanging silently)
3. Verify the deferred-init code path doesn't have a circular dependency in CLI-direct invocation (vs gateway-mediated)