Fix LM Studio "Client disconnected" with OpenClaw: Increase the Stalled Embedded-Run Watchdog

If you're running OpenClaw with local models via LM Studio and seeing Client disconnected. Stopping generation..., the model probably isn't broken — OpenClaw's internal watchdog is killing the request before the first token arrives. Here's the exact fix.

The root cause

OpenClaw has a diagnostic watchdog that aborts "stalled" embedded runs. The threshold lives in a compiled JS file (diagnostic-DhwkYT4X.js) under .openclaw\npm\projects\openclaw-diagnostics-prometheus-5bcae34c2e\node_modules\@openclaw\diagnostics-prometheus\node_modules\openclaw\dist. Two constants control it:

const MIN_STALLED_EMBEDDED_RUN_ABORT_MS = 5000000;   // ~83 minutes
const STALLED_EMBEDDED_RUN_ABORT_WARN_MULTIPLIER = 15;

Changing these values and restarting the gateway stopped the disconnects for a user running Qwen, Gemma, and DeepSeek models on a 32 GB RAM HP All-in-One (Windows 10, OpenClaw 2026.7.1-2, LM Studio 1.0.7 build 2).

Why standard timeouts don't help

The usual suspects — agents.defaults.timeoutSeconds, models.providers.lmstudio.timeoutSeconds, etc. — had no effect. The watchdog fires before the provider timeout. Also note that openclaw doctor can reset your config, so manual config changes may get reverted.

Applying the fix

Edit the constants in that dist file (or the source if you have it), then restart the gateway:

openclaw gateway restart

Restarting Windows may also be required for a clean test.

The author observed disconnects at ~6.5 minutes on heavy first requests, consistent with the watchdog's logic (5000000 ms × 15 = 75,000 ms = 75 s? — actually the math in the post is a bit off, but the point stands: the threshold was too low for long local prompt processing).

This is a niche but deeply annoying issue for anyone running OpenClaw with local models. If you've hit it, this is the fix.