Bug 1 — Bundled MCP tempDir cleaned up while persistent CLI subprocess still references it

Summary

In claude-live-session mode, the spawned claude -p --input-format stream-json subprocess persists across many turns (stored in the liveSessions Map and reused). Its argv permanently contains --mcp-config /tmp/openclaw-cli-mcp-XXXXXX/mcp.json. However, the bundled-MCP tempDir cleanup runs in the outer runCliAgent finally block — i.e. after every turn returns — which deletes the tempDir while the subprocess is still alive.

The subprocess only loaded the config at startup so the dangling reference is harmless until anything causes a re-read or respawn:

• supervisor respawn after no-output-timeout / overall-timeout
• live-session fingerprint mismatch on a later turn → closeLiveSession("restart") → fresh spawn re-using stale args
• MCP loopback child re-resolution

The user-visible failure manifests as a 180s no-output-timeout (CLI produced no output for 180s and was terminated), cycled through every model in the fallback chain, until the gateway's catch-all maps to a misleading "billing error" template (see Bug 2 below).

Affected version

[email protected]. The relevant code is in the bundled dist/ output; the original source is in src/agents/cli-runner/ per the .d.ts files (bundle-mcp.d.ts, execute.d.ts).

Repro

1. Run any agent that uses claude-cli backend with a bundled MCP config (default path).
2. Observe the spawned claude subprocess: ps -ef | grep claude.*--mcp-config /tmp/openclaw-cli-mcp-
3. After the first turn returns, observe that the tempDir referenced by --mcp-config no longer exists on disk:

   $ ls -d /tmp/openclaw-cli-mcp-XXXXXX/  # the one in the live process's argv
   ls: cannot access '/tmp/openclaw-cli-mcp-XXXXXX/': No such file or directory

4. Confirm the running subprocess still points at the now-missing path.
5. To force the failure surface: cause a respawn (e.g. trigger no-output-timeout). The new spawn uses the stale path → Error: MCP config file not found: /tmp/openclaw-cli-mcp-XXXXXX/mcp.json → FailoverError(reason: "timeout") → fallback model.

Reproduced manually:

$ claude -p "say OK" --model sonnet --setting-sources user \
    --mcp-config /tmp/openclaw-cli-mcp-XXXXXX/mcp.json \
    --plugin-dir /tmp/openclaw/openclaw-claude-skills-YYYYYY/openclaw-skills \
    --strict-mcp-config
Error: Invalid MCP configuration:
MCP config file not found: /tmp/openclaw-cli-mcp-XXXXXX/mcp.json

Root cause

prepareModeSpecificBundleMcpConfig (bundled into prepare.runtime-*.js) returns a cleanup that does fs.rm(tempDir, { recursive: true, force: true }). That cleanup is hung off context.preparedBackend.cleanup and invoked in runCliAgent (cli-runner-*.js):

} finally {
    await context.preparedBackend.cleanup?.();
}

For one-shot supervisor.spawn / managedRun.wait() runs this is correct (subprocess has exited). For the shouldUseClaudeLiveSession(context) branch in executePreparedCliRun (execute.runtime-*.js), the subprocess is intentionally persistent — so the cleanup must be deferred to the live-session lifecycle, not the per-turn one.

The same file already has the right pattern for the skills plugin: claudeSkillsPluginCleanupOwned = true transfers ownership to the live-session cleanup chain. The MCP config tempDir needs the same treatment.

Proposed fix (minimal, single-hunk)

--- a/src/agents/cli-runner/execute.ts
+++ b/src/agents/cli-runner/execute.ts
@@ -1205,6 +1205,11 @@ async function executePreparedCliRun(context, cliSessionIdToUse) {
                if (shouldUseClaudeLiveSession(context)) {
                    if (!hasJsonlOutput) throw new Error("Claude live session requires JSONL streaming parser");
                    claudeSkillsPluginCleanupOwned = true;
+                   // Live session keeps the spawned CLI subprocess alive across turns; that
+                   // subprocess still holds --mcp-config <tempDir>/mcp.json in its argv. Defer
+                   // the bundle-MCP tempDir cleanup to the live-session lifecycle so the outer
+                   // runCliAgent finally doesn't rm it out from under a still-running process.
+                   const ownedPreparedBackendCleanup = context.preparedBackend.cleanup;
+                   context.preparedBackend.cleanup = void 0;
                    const liveResult = await runClaudeLiveSessionTurn({
                        context,
                        args,
@@ -1224,7 +1229,12 @@ async function executePreparedCliRun(context, cliSessionIdToUse) {
                                }
                            });
                        },
-                       cleanup: claudeSkillsPlugin.cleanup
+                       cleanup: async () => {
+                           try {
+                               await claudeSkillsPlugin.cleanup();
+                           } finally {
+                               await ownedPreparedBackendCleanup?.();
+                           }
+                       }
                    });

Why it's safe:

• runClaudeLiveSessionTurn's existing cleanupDone guard makes the wrapped cleanup idempotent.
• For session-reuse turns (cleanupTurnArtifacts && session), the wrapped cleanup runs immediately — the freshly-prepared tempDir for that turn was never used by the persistent subprocess, so deleting it is correct.
• For first-turn / new-session creation, the cleanup is stored on the live session and only fires when the session closes.
• Outer cli-runner finally still calls context.preparedBackend.cleanup?.() but it's now void 0 — optional chaining makes it a no-op.
• One-shot mode (the else branch following the shouldUseClaudeLiveSession block) is untouched.

Patch verified locally against the bundled dist/execute.runtime-*.js (file still parses, node --check passes). Happy to send a PR if useful.

Bug 2 — Misleading "billing error" template when fallback chain exhausts

Summary

When the model-fallback runner exhausts all configured candidates with a mix of reason: "timeout" / reason: "auth" / etc., the user-visible delivery surface displays:

⚠️ API provider returned a billing error — your API key has run out of credits or has an insufficient balance. Check your provider's billing dashboard and top up or switch to a different API key.

This is wrong for OAuth subscriptions (subscriptionType: "max", no API key in play) and was wrong in the case I hit (Bug 1 — the failures were tempDir races, not quota or credit). It sent me chasing a billing problem that didn't exist.

Reproducible signal

The gateway log (/tmp/openclaw/openclaw-YYYY-MM-DD.log) holds the truth — model_fallback_decision events show the real reason/status/errorPreview:

"reason": "timeout", "status": 408, "errorPreview": "CLI produced no output for 180s and was terminated."
"reason": "auth",    "status": 401, ...

But by the time the message reaches the chat surface it's collapsed to the generic billing template.

Suggestion

Either:

1. Aggregate the per-candidate reasons and pick a more accurate human-facing message (e.g. "All N models timed out / auth-failed — see gateway log"), or
2. At minimum, suppress the billing-specific wording when the active auth profile is OAuth / subscriptionType: max (no credit-card concept applies).

The current behavior is debugging-hostile — the surfaced error actively contradicts what the underlying logs say.

Environment

• [email protected] (bundled CLI on Linux/WSL2)
• Auth: Claude Max OAuth (subscriptionType: max, rateLimitTier: default_claude_max_20x)
• Backend: claude-cli, primary model claude-opus-4-7 with full 4.6/4.5 fallback chain
• Surfaced via control-ui session attached to agent:main:main

Happy to provide trajectories or run targeted repros.