Standing order stuck in loop

[sacred basalt]

How do I prevent loops like this

[gaunt summit]

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

[snow temple]

First thing: what does openclaw --version show? Version matters here because this is runtime/agent-loop behavior.

For prevention, enable/tune tool-loop detection. The warning you’re seeing is the generic repeat detector: same tool + same args. By default the guard is off unless configured; when enabled, it warns at warningThreshold and blocks at criticalThreshold / circuit-breaker levels.

Example JSON5 config:

{
  tools: {
    loopDetection: {
      enabled: true,
      historySize: 30,
      warningThreshold: 5,
      criticalThreshold: 10,
      globalCircuitBreakerThreshold: 15,
      detectors: {

[snow temple]

        genericRepeat: true,
        knownPollNoProgress: true,
        pingPong: true,
      },
    },
  },
}

If this is only happening for the lead-scout agent, I’d put the override on that agent instead of globally:

{
  agents: {
    list: [

[snow temple]

      {
        id: "lead-scout",
        tools: {
          loopDetection: {
            enabled: true,
            warningThreshold: 5,
            criticalThreshold: 10,
            globalCircuitBreakerThreshold: 15,
          },
        },
      },
    ],
  },
}

[snow temple]

Docs: https://docs.openclaw.ai/tools/loop-detection and https://docs.openclaw.ai/gateway/configuration-reference#toolsloopdetection

The SessionWriteLockTimeoutError is likely aftermath from the runaway/abort path, not the root cause. Restart the gateway to clear the active run. If it keeps coming back after restart, please file it with the loop log + version here: https://github.com/openclaw/openclaw/issues — repeated Firecrawl calls followed by an abort-settle timeout and session lock is worth tracking as a bug, not just config tuning.

[sacred basalt]

this is version 2026.5.27 and you can find my config here https://cl1p.net/4565

[snow temple]

I could read the config. Two important things:

1. That paste contains live-looking credentials/API keys/passwords. Please delete the cl1p and rotate anything you pasted there. I won’t repeat them here.

2. Your config already has loop detection enabled:

tools.loopDetection.enabled: true
warningThreshold: 8
criticalThreshold: 16
globalCircuitBreakerThreshold: 24

So the warning part is working. The reason it may keep going is that the generic detector warns on “same tool + same args”, but the critical block usually needs repeated no-progress / identical outcomes. A search tool can return slightly different output each time, so it can keep warning without tripping the hard block.

The bigger config issue is here:

[snow temple]

agents.list[] id "lead-scout":
tools: {
  allow: ["*"],
  deny: ["web_search"]
}

and separately:

mcp.servers.firecrawl.enabled: true
plugins.entries.firecrawl.enabled: false

So lead-scout is denied OpenClaw’s normal web_search, but it has broad * access and can still call the direct MCP tool firecrawl__firecrawl_search. That matches your loop exactly.

[snow temple]

I’d change the agent from broad allow to a tight allowlist, or at minimum deny the looping MCP tool for that agent:

{
  id: "lead-scout",
  tools: {
    allow: [
      "web_search",
      "web_fetch",
      "memory_search",
      "memory_get"
    ],
    deny: [
      "firecrawl__firecrawl_search",
      "firecrawl__firecrawl_agent"
    ],

[snow temple]

    loopDetection: {
      enabled: true,
      warningThreshold: 5,
      criticalThreshold: 10,
      globalCircuitBreakerThreshold: 15
    }
  }
}

If you actually need Firecrawl, prefer exposing only the specific capability you want, not allow: ["*"]. If you don’t need the MCP server, disable mcp.servers.firecrawl.enabled.

Also: this is a local LM Studio model doing a fairly tool-heavy workflow. Local models can be much more loop-prone with tool calls, even when they look good at normal chat. For this lead-scout style agent, I’d test with a more tool-reliable/cloud model or ask in #models for current recommendations.

For the stuck lock: restart the gateway after changing config. Don’t delete the lock while the gateway/run is active. If the same embedded abort settle timed out + SessionWriteLockTimeoutError happens again on 2026.5.27 after the Firecrawl loop is blocked, that’s issue-worthy: https://github.com/openclaw/openclaw/issues

[snow temple]

Docs:
https://docs.openclaw.ai/tools/loop-detection
https://docs.openclaw.ai/gateway/configuration-reference#toolsallow--toolsdeny

[sacred basalt]

Local model is qwen3.6, there aren't any local models better than that? I definately want it to use firecrawl but I want the loop detection to work

[snow temple]

Qwen may be one of the stronger local options, but I wouldn’t make a hard ranking claim here — local tool-calling quality changes fast and depends a lot on the exact serving stack/template. For current “best local model for tools” advice, #models is the right place, and the docs caveat still applies: local models can work, but tool-heavy agent loops are where they tend to wobble. https://docs.openclaw.ai/concepts/models#model-discussions-community-notes

For Firecrawl: don’t disable it globally if you need it. Instead, make the lead-scout agent’s Firecrawl access explicit and make loop detection more aggressive for that agent.

Something like:

{
  id: "lead-scout",
  tools: {
    allow: [
      "firecrawl__firecrawl_search",
      "firecrawl__firecrawl_scrape",
      "memory_search",
      "memory_get"
    ],

[snow temple]

    deny: [
      "firecrawl__firecrawl_agent"
    ],
    loopDetection: {
      enabled: true,
      historySize: 20,
      warningThreshold: 3,
      criticalThreshold: 6,
      globalCircuitBreakerThreshold: 9,
      detectors: {
        genericRepeat: true,
        knownPollNoProgress: true,
        pingPong: true
      }
    }

[snow temple]

  }
}

The important change is removing allow: ["*"] for that agent. Give it the Firecrawl tools it actually needs, but don’t leave every MCP/plugin tool available.

One caveat: the log line you showed is the warning detector: “same Firecrawl search called repeatedly with identical arguments.” The hard block depends on the runtime deciding there is no progress, and search results may vary slightly between calls. If you still see repeated warnings past the new criticalThreshold, that’s probably a bug/gap in the detector for search tools and is worth filing with the log + config + 2026.5.27: https://github.com/openclaw/openclaw/issues

Docs for the config knobs: https://docs.openclaw.ai/tools/loop-detection

[sacred basalt]

ok, but clearly the thresholds didn't work, so is this a bug?

[snow temple]

Yeah — with the logs/config you showed, I’d call this a bug or at least a detector gap.

I checked the current source: firecrawl__firecrawl_search falls under the generic repeat detector, and that path is currently warning-only for “same tool + same args.” The criticalThreshold hard block is used for no-progress/polling/ping-pong style detection, not for generic repeated identical calls. So your thresholds didn’t “fail” exactly; the generic Firecrawl repeat case doesn’t currently escalate to a hard block just because it crosses criticalThreshold.

That means your expectation is reasonable, but the implementation doesn’t match it. The docs also make this easy to misunderstand because they describe criticalThreshold as blocking repetitive loop patterns generally.

Please file this as an issue with:

• version: 2026.5.27
• the loop log showing firecrawl__firecrawl_search called 10 times with identical arguments
• the relevant loopDetection config
• note that generic repeat warnings never escalate/block

Issue tracker: https://github.com/openclaw/openclaw/issues

Practical workaround for now: don’t rely on loopDetection alone for this exact case. Keep Firecrawl enabled, but restrict the agent’s tool set and add a standing instruction in that agent’s prompt like “Do not call firecrawl__firecrawl_search more than once with the exact same query; if results are insufficient, change the query or stop and report what’s missing.” Not perfect, but it gives the model a behavioral rail until the generic detector can hard-block repeated identical calls.

[sacred basalt]

I have put something in the standing order, but I guess that wasn't enough

[snow temple]

Right, that tracks. Standing orders are helpful, but they’re still model instructions, not a runtime enforcement layer. Once a local model gets into a tool-call rut, it can ignore or “forget” that instruction in the moment.

For now I’d use both:

1. Keep the standing order, but make it very concrete:

Never call firecrawl__firecrawl_search more than once with identical arguments in the same task. If the first call is insufficient, change the query, use firecrawl__firecrawl_scrape on a specific result URL, or stop and report what is missing.

2. Tighten the agent tool surface so it only has the Firecrawl tools it actually needs, not allow: ["*"].

3. File the detector gap as a bug, because this should be enforceable below the model layer. A config threshold named criticalThreshold is not very useful for this case if the generic repeat detector can only warn.

The standing order not being enough is exactly why this belongs in runtime loop detection.

[gaunt summit]

Thank you for marking this question as solved!

Learn more

https://answeroverflow.com/about