openclaw - 💡(How to fix) Fix [Bug]: Xiaomi/MiMo sessions can repeatedly relaunch exec after 'Command still running' instead of switching to process poll [1 participants]

Summary

Across multiple Xiaomi / MiMo-backed sessions, when the exec tool returns a non-terminal result like:

Command still running (session <id>, pid <pid>). Use process ...

OpenClaw can end up in a bad orchestration state where the agent issues another identical or near-identical exec instead of switching to process(action="poll").

This leads to repeated background process launches, token waste, noisy UX, and sessions that look like they are stuck in an infinite loop.

This is not benchmark-specific. A LongMemEval run surfaced it first, but I reproduced the same pattern in other Xiaomi/MiMo sessions as well.

Related but not identical issues

• #40040 Agent does not properly wait for exec tool with long-running commands
• #60407 [Bug]: Exec commands succeed but return no output (SIGKILL / "Command still running")
• #25627 [Bug]: coder agent repeats messages on exec running retries
• #28533 [Bug]: Cron agentTurn retries script execution in infinite loop, wasting tokens

Those are adjacent, but this report is specifically about cross-session repeated exec relaunch after non-terminal exec results, with Xiaomi/MiMo making it especially easy to trigger.

Expected behavior

After exec returns a non-terminal result, the next step should be one of:

1. follow the existing background command with process(action="poll"), or
2. stop and ask for intervention.

It should not keep launching new exec commands for the same in-flight operation.

Actual behavior

Observed failure pattern:

1. assistant launches exec
2. tool returns Command still running (...)
3. assistant interprets that as "not done, run again"
4. assistant launches another exec
5. OpenClaw accepts the new background session
6. loop repeats, creating process fan-out and visible self-spin

Concrete example

One representative repeated command pattern was:

openclaw cron list --json 2>/dev/null | grep -i -E "quota|配额|播报|codex.*health" | head -20

Instead of switching to process, the session kept re-issuing new exec calls after responses like:

• Command still running (session wild-orbit, pid ...)
• Command still running (session lucky-slug, pid ...)
• Command still running (session amber-bloom, pid ...)
• Command still running (session fresh-sable, pid ...)
• Command still running (session oceanic-forest, pid ...)

Cross-session evidence

A scan of recent Xiaomi transcript files found 7 separate sessions with the same class of artifact (Command still running loops), including counts like:

• 33 hits in one session
• 21 hits in another
• 17 hits in another
• 5 hits in another

So this does not appear limited to one benchmark or one accidental prompt.

Diagnosis

This looks like a combined model + runtime orchestration bug.

Model-side weakness

Xiaomi / MiMo appears less reliable in tool-state transitions here. In failing cases, it treats Command still running as if rerunning exec is acceptable, instead of following the existing process.

Runtime-side missing guardrail

A robust runtime should prevent one bad tool decision from turning into runaway process fan-out.

OpenClaw currently appears to lack one or more of these protections:

• dedupe identical in-flight exec commands
• force or strongly bias process after non-terminal exec
• per-session / per-turn circuit breaker for repeated identical exec
• explicit structured state indicating that rerunning exec is invalid and process is required

Minimal reproduction idea

1. Use a Xiaomi / MiMo-backed agent session.
2. Ask it to run a shell command through exec that is likely to remain running long enough to background.
3. Wait for the tool to return Command still running (...).
4. Observe the next tool call.
5. In failing cases, the model issues another exec instead of process(action="poll").

Suggested fixes

1. Runtime dedupe

   • If the same session tries to issue an identical exec while an earlier one is still running, block or coalesce it.

2. Force correct follow-up tool

   • After a non-terminal exec result, expose a structured field such as requiredFollowupTool=process and reject repeated exec by default.

3. Circuit breaker

   • Stop repeated identical exec launches after N retries in one turn/session and surface an explicit error.

4. Telemetry / detection

   • Track a metric like exec_retry_after_still_running so this can be measured across providers/models.

5. Provider-aware routing

   • Consider preventing Xiaomi / MiMo from being the default orchestration driver for workflows that depend on background exec + process state machines.

Environment

• OpenClaw: observed on 2026.4.x
• Provider/model in the failing sessions: xiaomi/mimo-v2-pro
• Surface where first noticed: benchmark driving, then reproduced in non-benchmark maintenance/debug sessions as well

If useful, I can provide more transcript excerpts or tighter repro steps.