#openclaw agent stuck

1 messages · Page 1 of 1 (latest)

glass gardenBOT
#

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

quaint capeBOT
quasi mapleBOT
#

First thing, can you paste:

openclaw --version

Then reproduce it once and share these:

openclaw status --all
openclaw models status
openclaw logs --follow

Also tell me what model/provider you’re using.

Two common causes for this exact kind of “stuck making code” behavior:

#

  1. Local/OpenAI-compatible backends choking on tool calls

    • especially Ollama/LM Studio/vLLM-style setups
    • if you’re using Ollama, use the native base URL like http://127.0.0.1:11434
    • do not use /v1 for Ollama, tool calling gets flaky there

  2. The agent is looping the same tool call

    • OpenClaw has loop detection, but it’s off by default
    • if logs show repeated identical tool calls, that’s likely it

Docs:

Paste the version + status/log output and I’ll help narrow it down fast.

#

Yeah, the timeout is the real problem. The other lines are mostly config smell, not the actual crash.

What each line means:

  • unknown allowlist entries

    • not fatal by itself
    • update_plan is experimental
    • x_search and code_execution are xAI-backed
    • image_generate / music_generate / video_generate only exist when those providers are configured
    • apply_patch is available by default for OpenAI / OpenAI Codex, not Ollama

  • missing memory\2026-04-22.md

    • usually harmless, just a missing file read

  • Profile ollama:default timed out

    • this is the real blocker
    • the agent timed out while using ollama/qwen3.5:9b
#

Also, one important thing: if you’re using tools.profile: "minimal", that profile only gives session_status by default. That is the wrong base profile for a coding agent.

What I’d change

  1. Stop using minimal for this agent
    Use tools.profile: "coding" or explicitly allow:

    • group:fs
    • group:runtime

  2. Remove unavailable tools from tools.allow
    For coding on Ollama, the useful ones are file/runtime tools, not code_execution.
    code_execution is xAI’s remote Python sandbox, not local file creation.

  3. If this is remote Ollama, make sure your base URL does not end in /v1
    Use:

    • http://host:11434
      not:
#
  • http://host:11434/v1
  1. Try lean mode for weaker local models
    qwen3.5:9b may just be choking on the full prompt/tool surface.
{
  tools: { profile: "coding" },
  agents: {
    defaults: {
      experimental: { localModelLean: true }
    }
  }
}

If it still times out after that, I’d test a stronger model or a hosted fallback. Small local models get pretty shaky for agentic coding.

#

Yep, let’s do it step by step. I’ll assume you’re in PowerShell on Windows.

1. Check your version first

Run:

openclaw --version

Copy the output somewhere, we may need it later.

2. See what your tools config looks like

Run these one by one:

# 
openclaw config get tools.profile
openclaw config get tools.allow --json
openclaw config get agents.list --json

What you’re looking for:

  • if tools.profile says minimal, that’s a problem for coding
  • in agents.list, look for the agent with "id": "main"

3. Change the global tool profile to coding

Run:

# 
openclaw config set tools.profile coding

Then verify it changed:

openclaw config get tools.profile

It should now say:

coding
#

4. Remove the bad global allowlist if you have one

If openclaw config get tools.allow --json showed a custom list with things like:

  • apply_patch
  • code_execution
  • update_plan
  • image_generate
  • music_generate
  • video_generate
  • x_search

then remove that whole global allowlist for now:

openclaw config unset tools.allow
#

Then check it:

openclaw config get tools.allow --json

It should come back empty / unset.

5. Remove the bad allowlist from the main agent too

From the agents.list --json output, find the index of the agent whose id is "main".

If "main" is the first one, its index is 0.
If it’s the second, its index is 1, etc.

#

Then run this, replacing 0 with the right index if needed:

openclaw config unset agents.list[0].tools.allow

Optional, also check whether that agent has its own profile override:

openclaw config get agents.list[0].tools.profile

If that also says minimal, remove it:

openclaw config unset agents.list[0].tools.profile
#

That lets it inherit the global coding profile you set above.

6. Check your Ollama base URL

Run:

openclaw config get models.providers.ollama.baseUrl

If it ends with /v1, fix it.

For local Ollama, use:

# 
openclaw config set models.providers.ollama.baseUrl "http://127.0.0.1:11434"

Important: no /v1.

7. Turn on local-model lean mode

This helps weaker local models handle OpenClaw better.

Run:

openclaw config set agents.defaults.experimental.localModelLean true --strict-json
#

Then verify:

openclaw config get agents.defaults.experimental.localModelLean

It should say true.

8. Restart OpenClaw

Run:

openclaw gateway restart
#

Wait for it to come back up, then check:

openclaw status

9. Test the agent again

Try a very small coding request first, like:

create a hello.py file that prints hello

If it still hangs, immediately run:

# 
openclaw logs --follow

Look for another line like:

  • Profile ollama:default timed out

If you still get that, then the main issue is likely the Ollama model itself being too slow/weak for agentic coding.

10. If it still fails, send me these outputs

Paste these:

# 
openclaw --version
openclaw config get tools.profile
openclaw config get tools.allow --json
openclaw config get agents.list --json
openclaw config get models.providers.ollama.baseUrl
openclaw config get agents.defaults.experimental.localModelLean
openclaw status --all

If you want, send me the output from step 2 first, and I’ll tell you exactly which index to use for agents.list[...].

#

Nice, that’s actually good.

  • tools.allow not found = you do not have a global allowlist
  • global profile already being coding = also good

So the warning is probably coming from the agent-specific config for main, and the timeout is still likely the real blocker.

Next step

Run these:

openclaw config get agents.list --json
openclaw config get models.providers.ollama.baseUrl
openclaw config get agents.defaults.experimental.localModelLean
#

What I want you to check

1. In agents.list --json

Look for the entry with:

"id": "main"

See if that agent has a tools.allow block.

If it does, paste that part here.

2. In models.providers.ollama.baseUrl

If it ends in /v1, that needs fixing.

If it does, run:

# 
openclaw config set models.providers.ollama.baseUrl "http://127.0.0.1:11434"

(no /v1)

3. In agents.defaults.experimental.localModelLean

If it says Config path not found or false, turn it on:

openclaw config set agents.defaults.experimental.localModelLean true --strict-json

Don’t restart yet, do those checks first.

Paste the output from those 3 commands and I’ll tell you the exact next command.

#

Nice, we found it.

Your main agent is overriding the global setting here:

"tools": {
  "profile": "minimal",

So even though the global profile is coding, the main agent is still using minimal.

Do these exact steps

1. Remove the main agent’s minimal override

Run:

# 
openclaw config unset agents.list[0].tools.profile

Why: that makes main inherit the global coding profile.

Check it worked:

openclaw config get agents.list[0].tools.profile

It should now say Config path not found.

2. Remove that huge custom alsoAllow list for now

#

Run:

openclaw config unset agents.list[0].tools.alsoAllow

Why: that list includes a bunch of tools that either:

  • are not available on Ollama
  • need extra providers/config
  • or are just not valid tool names for this runtime

So it’s creating noise and confusion.

Check it worked:

# 
openclaw config get agents.list[0].tools.alsoAllow --json

It should come back empty / not found.

3. Turn on lean mode for the local Ollama model

Run:

openclaw config set agents.defaults.experimental.localModelLean true --strict-json

Check it:

# 
openclaw config get agents.defaults.experimental.localModelLean

It should say:

true

4. Check your Ollama base URL

Run:

# 
openclaw config get models.providers.ollama.baseUrl

If it ends with /v1, fix it with:

openclaw config set models.providers.ollama.baseUrl "http://127.0.0.1:11434"

Use your real host/port if different, but no /v1.

5. Restart the gateway

Run:

# 
openclaw gateway restart

Then verify:

openclaw status

6. Test with a tiny coding task

Try something simple like:

create a hello.py file that prints hello

#

If it still hangs, immediately run:

openclaw logs --follow

and paste the new timeout lines.

Important note

That alsoAllow list had things like:

  • apply_patch on Ollama
  • update_plan
  • code_execution
  • x_search
  • ollama_web_fetch
#
  • ollama_web_search

A bunch of those are either unavailable, experimental, xAI-only, or just not the right tool names here.

So step 2 is a good cleanup, not just a guess.

Paste the outputs from steps 1 to 4 if you want me to check before you restart.

#

Perfect, step 1 worked, and thanks, now we also have your version: 2026.4.15. That’s recent enough that I’m not immediately worried about version mismatch.

Next step

Run this:

openclaw config unset agents.list[0].tools.alsoAllow
openclaw config get agents.list[0].tools.alsoAllow --json

What should happen

The second command should say:

Config path not found: agents.list[0].tools.alsoAllow
#

If that works, do these right after:

openclaw config set agents.defaults.experimental.localModelLean true --strict-json
openclaw config get models.providers.ollama.baseUrl

If the Ollama URL ends with /v1

fix it with:

openclaw config set models.providers.ollama.baseUrl "http://127.0.0.1:11434"

Then restart:

# 
openclaw gateway restart
openclaw status

If you want to keep going step by step, just paste the output from the alsoAllow check and the Ollama base URL, and I’ll give you the next exact line.

#

Perfect, that URL is good.

http://127.0.0.1:11434 means the /v1 mistake is not the issue.

So now the most likely problem is still the local Ollama model timing out.

Next commands

Run these:

openclaw config get agents.list[0].tools.alsoAllow --json
openclaw config set agents.defaults.experimental.localModelLean true --strict-json
openclaw config get agents.defaults.experimental.localModelLean

What I expect

#
  • agents.list[0].tools.alsoAllow should ideally say Config path not found
  • agents.defaults.experimental.localModelLean should say true

After that

Restart OpenClaw:

openclaw gateway restart
openclaw status

Then test again

Give it a tiny request like:

create a hello.py file that prints hello

#

If it still hangs, run:

openclaw logs --follow

and paste the new timeout lines.

At this point we’ve ruled out:

  • bad global tool profile
  • bad per-agent profile
  • bad Ollama /v1 URL

So if it still stalls after lean mode, the next suspect is just qwen3.5:9b not coping well with agentic coding.

#

Yep, that audit pretty much confirms it.

ollama/qwen3.5:9b is too small for safe unsandboxed agent use, and it also fits the “gets stuck on coding tasks” behavior.

You have 2 paths

Option 1, recommended: switch to a stronger model

This is the easiest way to actually fix the “stuck making Python code” problem.

Option 2: keep qwen3.5:9b, but lock it down

If you want to stay on that model, do this:

Step 1, check if Docker is installed

Run:

# 
docker --version

If that works, continue.

Step 2, enable sandboxing for all sessions

openclaw config set agents.defaults.sandbox.mode all

Step 3, disable web tools and browser

openclaw config set tools.deny '["group:web","browser"]' --strict-json
#

Step 4, keep lean mode on

If you already set it, great. If not:

openclaw config set agents.defaults.experimental.localModelLean true --strict-json

Step 5, restart

openclaw gateway restart
openclaw status

Step 6, test again

Try:

#

create a hello.py file that prints hello

My honest recommendation

If your goal is actually using OpenClaw for coding, I would not fight too hard to make a 9B Ollama model do full agentic coding. It’s possible to make it safer, but not necessarily pleasant.

If you want, I can do either of these next:

  1. walk you through the safe qwen3.5:9b sandbox setup, or
  2. walk you through switching to a stronger model

I’d personally pick 2 unless you specifically want the local-only route.

Docs:

#

This looks more like a config/model-capability mismatch than a maintainer bug right now.

A 9B local model getting flagged by the security audit and timing out on agentic coding is pretty expected.

If it still breaks after:

  • removing the minimal override,
  • cleaning the custom tool list,
  • enabling localModelLean,
  • and either sandboxing it or trying a stronger model,

then yep, please file a GitHub issue with:

  • openclaw --version
  • openclaw status --all
  • relevant config bits
  • the timeout logs

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

daring vapor
quasi mapleBOT
#

Probably not because of removing the allow list.

With tools.profile: "coding", the agent still gets the normal coding tools through the profile, including filesystem/runtime basics. So removing that huge custom alsoAllow should not by itself stop normal file creation.

What’s more likely is one of these:

  1. The model said it created the file, but never actually called write/edit

    • small local models do this a lot

  2. Sandboxing is on, and the file was written into the sandbox workspace

    • with default workspaceAccess: "none", sandbox writes go under ~/.openclaw/sandboxes, not your normal workspace

Check these

Run:

# 
openclaw config get agents.defaults.sandbox.mode
openclaw config get agents.defaults.sandbox.workspaceAccess

Then search both places:

Get-ChildItem "$HOME\.openclaw\workspace" -Recurse -Filter *.py
Get-ChildItem "$HOME\.openclaw\sandboxes" -Recurse -Filter *.py

Best check of all

Do one fresh test, then immediately run:

# 
openclaw logs --follow

If you don’t see a real write / edit tool call, then the model likely hallucinated success instead of actually creating the file.

If you paste:

  • sandbox.mode
  • sandbox.workspaceAccess
  • and the log lines right after a failed “I created the file”

I can tell you which of the two it is.

daring vapor
#

im not using a sandbox

quasi mapleBOT
#

Got it, then that makes it a lot simpler.

If you’re not using a sandbox, then the removed allowlist is probably not the reason.

With the coding profile, the agent should still have normal file tools. So if it says “I created the file” and nothing exists, the most likely explanation is:

the model hallucinated success and never actually called the file-writing tool.

That’s pretty common with a small local model like qwen3.5:9b.

Check the actual workspace

Run:

openclaw config get agents.defaults.workspace
#

If that path isn’t set, the default is usually your OpenClaw workspace under:

C:\Users\lochy\.openclaw\workspace

Then search for Python files there:

Get-ChildItem "$HOME\.openclaw\workspace" -Recurse -Filter *.py

Check whether it really used a file tool

Do one fresh test, then immediately run:

# 
openclaw logs --follow

What we want to see is a real tool call like:

  • write
  • edit
  • maybe apply_patch

If you don’t see one of those, then the model just claimed it wrote the file.

Short version

  • No sandbox = file should be in the normal workspace
  • Not likely caused by removing alsoAllow
  • Most likely = the 9B model is bluffing instead of actually writing files
#

If you paste:

  1. the exact “I created the file” reply, and
  2. the log lines right after it,

I can tell you for sure.

#

Yep, this confirms it.

The important line is this one:

Profile ollama:default timed out
...
stage":"assistant"
...
"model":"qwen3.5:9b"

That means the model timed out before it successfully finished the turn.

So the answer is:

No, the removed allowlist is probably not why the file is missing.

#

The model most likely never actually wrote the file.

What your log is saying

  • tool availability warnings → config noise, not the main failure
  • missing memory\2026-04-22.md → annoying but not the reason coding failed
  • Ollama timeout → this is the real issue
  • no write / edit / apply_patch lines shown → no evidence a file was actually created
  • openclaw get plugin error → unrelated to the coding failure

What I’d do next

Best fix

Use a stronger model for coding.

One last try with this model

If you want to give qwen3.5:9b one more shot, increase the idle timeout:

# 
openclaw config set agents.defaults.llm.idleTimeoutSeconds 300 --strict-json
openclaw gateway restart

Then test again.

My honest read

We’ve basically pinned it down now:

  • not a sandbox issue
  • not mainly the allowlist cleanup
  • not the Ollama URL
  • mostly the 9B model timing out / bluffing

If you want, I can walk you through either:

#
  1. raising the timeout and retrying, or
  2. switching to a stronger model

I’d recommend 2.

#

Yep, this is basically the smoking gun.

Those two lines:

I'll create a Python program...
Perfect! I've created a Python program...

are just the assistant’s text output.

In that same log slice, the only real tool activity we can see is:

node.list
#

There’s still no evidence of an actual file-writing tool call like:

  • write
  • edit
  • apply_patch
  • or even an exec doing file creation

So the model is narrating work it did not actually perform.

What this means

This is not mainly an allowlist problem anymore.

It looks like a small-model tool-discipline / hallucination problem with ollama/qwen3.5:9b.

Quick check

#

See if that folder actually exists:

Get-ChildItem "$HOME\.openclaw\workspace\thought-sharer" -Force

If it doesn’t exist, that confirms it.

My recommendation now

At this point I would stop tuning the allowlist and switch to a stronger model for coding.

If you want one last try before switching, do this:

openclaw config set agents.defaults.llm.idleTimeoutSeconds 300 --strict-json
# 
openclaw gateway restart

But honestly, the bigger issue here is that the model is claiming success without doing the file operations.

If you want, I can now help with exactly one of these:

  1. switch to a stronger model, or
  2. set stricter guardrails for local-only use

For actually making Python files, I’d pick 1.

daring vapor
#

is that 300 seconds or?

quasi mapleBOT
#

Yep, 300 seconds, so 5 minutes.

openclaw config set agents.defaults.llm.idleTimeoutSeconds 300 --strict-json

Just a heads-up, this only helps if the model is slow. It won’t fix the bigger issue if the 9B model is hallucinating tool success.

daring vapor
#

how do I confirm it saved those changes?

quasi mapleBOT
#

Easiest way is just read the value back:

openclaw config get agents.defaults.llm.idleTimeoutSeconds

If it saved correctly, it should print:

300

If you want to double-check the file itself too:

openclaw config file
#

That shows which openclaw.json is active.

Then you can inspect that file manually, or just do:

openclaw config validate

So the quick confirmation flow is:

openclaw config get agents.defaults.llm.idleTimeoutSeconds
openclaw config validate
openclaw gateway restart
openclaw status
daring vapor
quasi mapleBOT
#

If you’re on native Windows, the gateway doesn’t need to open a visible gateway.cmd window to be working.

What you described, random terminal windows popping up, sounds more like:

  • a stale old startup item / scheduled task, or
  • the Windows Startup-folder fallback kicking in after reinstall

So first, let’s check whether the gateway is actually running now.

Run these in order

openclaw status
openclaw gateway status
openclaw doctor

What I’m looking for

#

From openclaw gateway status, paste back:

  • Service: ...
  • Runtime: ...
  • Connectivity probe: ...

From openclaw doctor, I want to know if it mentions:

  • legacy service
  • extra gateway installs
  • schtasks
  • repair / cleanup hints

My guess right now

You probably have more than one Windows startup path active after reinstall, and one of them is opening that random terminal.

Also, not seeing gateway.cmd open is not automatically bad. On Windows, OpenClaw prefers a Scheduled Task, and only falls back to a visible login startup item if task creation was denied.

daring vapor
quasi mapleBOT
#

Yep. For a full clean uninstall on Windows, I’d do this.

Warning

This removes your:

  • config
  • sessions/state
  • workspace files
  • gateway startup task

If there’s anything you want to keep, back up C:\Users\lochy\.openclaw first.

Easiest path, if the CLI still works

Run:

# 
openclaw uninstall --all --yes --non-interactive

Then do the Windows cleanup manually too

Remove the Scheduled Task:

schtasks /Delete /F /TN "OpenClaw Gateway"

Remove the gateway script if it still exists:

Remove-Item -Force "$env:USERPROFILE\.openclaw\gateway.cmd" -ErrorAction SilentlyContinue
#

Remove all OpenClaw state/config/workspace:

Remove-Item -Recurse -Force "$env:USERPROFILE\.openclaw" -ErrorAction SilentlyContinue

If you used a profile, also remove those dirs too, for example:

Remove-Item -Recurse -Force "$env:USERPROFILE\.openclaw-*" -ErrorAction SilentlyContinue

Remove the CLI install

If you installed with npm:

# 
npm rm -g openclaw

If you used pnpm instead:

pnpm remove -g openclaw

If you installed from a git checkout

Delete the repo folder too after uninstalling the gateway task/service.

Important

If the random terminal window still appears after all this, then you almost certainly still have a leftover:

  • Scheduled Task, or
  • Startup-folder item
daring vapor
#

22:39:07 [agent/embedded] embedded run agent end: runId=31898330-bc01-4f0c-81b3-2772b80b90e6 isError=true model=gemma4 provider=ollama error=404 {"error":"model 'gemma4' not found"} rawError=404 {"error":"model 'gemma4' not found"}
22:39:07 [agent/embedded] auth profile failure state updated: runId=31898330-bc01-4f0c-81b3-2772b80b90e6 profile=sha256:9c018ec112cf provider=ollama reason=model_not_found window=cooldown reused=false
22:39:07 [agent/embedded] embedded run failover decision: runId=31898330-bc01-4f0c-81b3-2772b80b90e6 stage=assistant decision=surface_error reason=model_not_found from=ollama/gemma4 profile=sha256:9c018ec112cf

quasi mapleBOT
#

This one is simpler, OpenClaw is trying to use:

ollama/gemma4

but Ollama is replying:

model 'gemma4' not found

So either:

  1. gemma4 is not installed locally, or
  2. the model name/tag in config doesn’t exactly match what Ollama has
#

Fix it

1. See what Ollama actually has installed

ollama list

2. If gemma4 is missing, pull it

ollama pull gemma4

3. Or set OpenClaw to a model you already have installed

Use the exact model name from ollama list:

# 
openclaw models set ollama/<exact-model-name>

Example shape:

openclaw models set ollama/gemma4

or if your installed one includes a tag:

openclaw models set ollama/gemma4:latest

4. Then verify

# 
openclaw models status
openclaw gateway restart

Short version

This is not the old timeout issue, this is just:

configured model name != model actually installed in Ollama

If you paste the output of:

ollama list