#openclaw failing silentl

1 messages · Page 1 of 1 (latest)

feral patrolBOT
vital escarpBOT
#

That pattern usually means the child got through its first write, then hit either a timeout or a non-interactive permission failure.

Please paste these first:

openclaw --version
openclaw status --all
openclaw logs --follow

Then reproduce it once, and grab:

/subagents list
/subagents info <id>
/subagents log <id> 100 tools
#

Two common causes here:

  1. Regular subagent timeout
    Regular subagents do not time out by default, default is runTimeoutSeconds: 0, so if you see timed out, something is setting a timeout.
    Check:
openclaw config get agents.defaults.subagents.runTimeoutSeconds
  1. ACP harness session (Codex / Claude Code / Gemini CLI)
    These default to a 120s runtime timeout, and non-interactive permission prompts can kill writes/exec with AcpRuntimeError.
    If your logs show that, the usual fix is:
openclaw config set plugins.entries.acpx.config.timeoutSeconds 180
#

Run them with OpenClaw running.

Best way:

  1. Keep the gateway/openclaw running
  2. In one terminal:
    openclaw --version
openclaw status --all
  3. In a second terminal:
    openclaw logs --follow
  4. Leave that log window open, then trigger the failing subagent again
  5. Paste the error/timed-out lines here
#

Quick rule:

  • openclaw --version = anytime
  • openclaw status --all = best while running
  • openclaw logs --follow = definitely while running, and while reproducing the bug

So, don’t close everything first. If anything, we want it alive so it can fail in front of the logs.

vital escarpBOT
#

Yeah, that sounds more like the Ollama model/backend than subagents.

If /new is hanging too, the reset command itself is probably fine, and the active model is choking on the first turn.

Try this:

openclaw --version
openclaw models status
openclaw logs --follow

And in another terminal, test the model directly:

openclaw infer model run --model ollama/<your-model> --prompt "say hi" --json
#

A couple likely causes with local/Ollama setups:

  1. Model is too slow, and OpenClaw aborts on the LLM idle timeout
    You can raise it:
openclaw config set agents.defaults.llm.idleTimeoutSeconds 180
openclaw gateway restart
  1. Model/backend handles tiny prompts, but not full OpenClaw agent turns
    That is a common local-model issue. If the direct test works but /new still hangs, it usually means the local model cannot handle the full prompt/tool load reliably.

As a quick sanity check, switch to a non-Ollama model once. If /new suddenly works, you’ve basically confirmed it’s the local model path.

Docs:

#

Yep, the logs confirm it.

The important line is:

[llm-idle-timeout] ollama/qwen3.5:9b produced no reply before the idle watchdog

So this is not really a subagent bug. OpenClaw is waiting on Ollama/qwen3.5:9b, gets no response in time, retries, then gives up. Also:

fallbackConfigured:false

means there is no backup model to fail over to.

What I’d do first

#
  1. Raise the LLM idle timeout
openclaw config set agents.defaults.llm.idleTimeoutSeconds 180
openclaw gateway restart
  1. Test the model directly
openclaw infer model run --model ollama/qwen3.5:9b --prompt "say hi" --json
  1. Try again
    If it still hangs, then qwen3.5:9b via Ollama is probably just too slow / too weak / too unreliable for OpenClaw’s full agent prompt + tools flow.

My honest read

For actual agentic work, small local Ollama models are usually the pain point. They can work for light chat, but OpenClaw is much heavier than that. So if you want this to be stable, I’d strongly test with:

#
  • a stronger model, or
  • a hosted fallback model

About this warning

agents.main.tools.allow allowlist contains unknown entries ...

That is a separate config issue, not the timeout cause. Worth cleaning up later, but the timeout is the main blocker.

Docs:

If you want, paste what happens after setting agents.defaults.llm.idleTimeoutSeconds to 180, and I’ll help you tune it from there.

#

Ah, that part is a different issue.

Those keys shouldn’t just randomly flip unless one of these is happening:

  1. OpenClaw is restoring the last-known-good config after rejecting an edit
  2. Another OpenClaw config writer, like configure, doctor, or a UI save, is overwriting the file
  3. You’re editing a file that is not the active config file

First check the real config path

openclaw config file
openclaw config validate
openclaw logs --follow

In the logs, look for messages like:

#
  • Config auto-restored from last-known-good
  • Config write rejected:
  • config reload restored last-known-good config

If you see those, OpenClaw is rejecting an edit and restoring the previous good config.

Safer way to set those flags

Instead of hand-editing the file, do:

openclaw config set tools.web.fetch.enabled true --dry-run
openclaw config set tools.web.search.enabled true --dry-run
openclaw config set tools.web.fetch.enabled true
openclaw config set tools.web.search.enabled true
openclaw config validate
#

Also, for web.search, turning it on is only half of it. You still need a search provider configured:

openclaw configure --section web

Important detail

Per docs, this is expected behavior:

  • tools.web.search.enabled: false disables web search
  • tools.web.fetch.enabled: false disables web fetch

So if they keep going back to false, something is definitely writing or restoring config.

My guess

#

It means Control UI insecure-auth compatibility is turned on:

gateway.controlUi.allowInsecureAuth = true

In plain English, OpenClaw is allowing a less secure localhost HTTP auth path for the dashboard/Control UI. It warns because that setting is meant as a compatibility / break-glass toggle, not the normal setup.

If you do not need it

Turn it off:

openclaw config set gateway.controlUi.allowInsecureAuth false
openclaw gateway restart
#

Then run:

openclaw security audit

If you do need dashboard access

Recommended options are:

  • local machine only: http://127.0.0.1:18789/
  • remote access: use HTTPS, ideally Tailscale Serve

Important nuance

This flag is localhost compatibility only.

#

Yep, that would absolutely do it.

That error means you already have one OpenClaw gateway running, and then a second one tried to start on the same port.

So right now the problem is probably duplicate gateway instances, not subagents.

What to do

Run:

openclaw gateway status

If one is already running, do not start another one.

Then clean it up with:

# 
openclaw gateway stop
openclaw gateway start

or just:

openclaw gateway restart

Very common cause

You have:

  • one gateway running as the installed daemon/service
  • and another one started manually in a terminal
#

Those will fight each other.

Rule of thumb

You want exactly one gateway running.

After restarting, check:

openclaw status --all

If it still won’t answer, paste the output of:

openclaw gateway status
# 
openclaw status --all

and I’ll help you sort the rest out.

#

Nice, glad it’s responding again. 🎉

That means it probably was a config issue after all.

I’d still do two quick checks so it doesn’t bite you again:

openclaw config validate
openclaw security audit

And for future edits, I’d really use:

openclaw config set ...
#

instead of hand-editing openclaw.json, because hot reload / last-known-good recovery can get weird.

If the original subagent timeout comes back, the next likely culprit is still your Ollama model timing out, so keep an eye on that llm-idle-timeout log.

Glad that helped! 🎉
If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution.
This helps Answer Overflow index the solution for future users.

#

Yeah, you shouldn’t have to babysit it.

To make it stick, do it through the CLI instead of hand-editing the file:

openclaw config set tools.web.fetch.enabled true
openclaw config set tools.web.search.enabled true
openclaw config validate

Then make sure web search is actually configured too:

openclaw configure --section web

Also check these 3 things

#
  1. You’re editing the real config file
openclaw config file
  1. Nothing is restoring old config
    Leave this running and watch for:
  • Config auto-restored from last-known-good
  • Config write rejected:
openclaw logs --follow
  1. Nothing else is overwriting config
    If you run onboarding/configure/another gateway instance, one of those may be writing the config back.
#

Important detail

tools.profile: "coding" does not force web on by itself.
If tools.web.fetch.enabled or tools.web.search.enabled gets set to false, that is still a hard off switch.

Best “make it stick” flow

Run these once:

openclaw config set tools.web.fetch.enabled true
openclaw config set tools.web.search.enabled true
openclaw configure --section web
openclaw config validate
openclaw gateway restart
#

If it flips back again, paste the exact Config auto-restored... or Config write rejected... log line, because then we’ll know exactly what is overwriting it.

#

Ah, that’s the real clue.

You have a path/user mismatch:

  • active config: C:\Users\wispy\.openclaw\openclaw.json
  • backup path: C:\Users\lochy\.openclaw\openclaw.json.bak

That is not normal. It means OpenClaw is resolving config/home from two different user paths, so one run or env var is likely still pointing at the old lochy home.

Most likely causes

  • OPENCLAW_HOME is set to the old user path
  • OPENCLAW_CONFIG_PATH or OPENCLAW_STATE_DIR is set somewhere
  • one gateway/service was installed under the old user, another under the new one

Check this in the same terminal you use for OpenClaw

# 
openclaw config file
echo %OPENCLAW_HOME%
echo %OPENCLAW_CONFIG_PATH%
echo %OPENCLAW_STATE_DIR%
echo %USERPROFILE%

If any of those point to C:\Users\lochy, that’s the thing to fix.

What you want

Everything should resolve to the same user/home, probably C:\Users\wispy\...

Quick fix

If those env vars are wrong, clear them in your current shell and retry:

# 
set OPENCLAW_HOME=
set OPENCLAW_CONFIG_PATH=
set OPENCLAW_STATE_DIR=

Then check again:

openclaw config file

If you installed the gateway/service before under the old user

You may need to reinstall/restart it from the correct account after fixing env.

Why this matters

#

Ah, got it, thanks, that makes more sense.

In that case, this line is normal:

Config overwrite: ... openclaw.json ... backup=...openclaw.json.bak

It just means OpenClaw wrote the config and made a backup first. That is not the thing flipping it back.

So the “good” way to make it stick is:

openclaw config set tools.web.fetch.enabled true
openclaw config set tools.web.search.enabled true
openclaw configure --section web
# 
openclaw config validate
openclaw gateway restart

Important distinction

  • Config overwrite ... backup=... = normal save
  • Config auto-restored from last-known-good = your change got reverted
  • Config write rejected: = your change was refused

So if it keeps turning back off, the log line we care about is one of the last two, not Config overwrite.

Short version

If you want it permanently enabled:

#
  1. set it with openclaw config set
  2. configure web with openclaw configure --section web
  3. validate
  4. restart once

If it still flips after that, paste the exact log line around the moment it changes, and we’ll catch what is writing it back.