Agent stops working | Friends of the Crustacean 🦞🤝 | Page 1

broken otter May 10, 2026, 8:09 AM

#

@modest vector
I have a problem where agent stops working. I installed openclaw with the curl command on the mainpage of the site. I prompt it to create a apache webserver and at first it starts doing stuff but then it just stops
My prompt: Hello, can you setup apache webserver here
Respoinse: Hello! I'd be happy to help you set up an Apache webserver. Before I proceed, let me check what system we're working with and ensure we have the necessary permissions.
Now let me check if Apache is already installed and what version we're working with:
It looks like Apache is not installed on this system yet. Let me install it for you:
I see that we need elevated permissions to install Apache. Let me check if we can use the gateway with elevated permissions:
[assistant turn failed before producing content]
I say continue but it doesnt even show up as sent, only appears after around 15 seconds, agent sometimes doesnt even respond. Now the agent is unresponsive with connected | idle

modest vectorBOT May 10, 2026, 8:09 AM

#

This looks less like an Apache problem and more like the agent turn is crashing right when it hits elevated exec / approval. apt install apache2 needs root, so the important clue is the line right before the failure: “check if we can use the gateway with elevated permissions”.

First thing: what version are you on?

openclaw --version

Then please run these and paste the output/log tail here:

openclaw status --all
openclaw gateway status
openclaw logs --follow

If you just need to unstick it immediately, try:

#

openclaw gateway restart

Also check whether an approval prompt/card appeared somewhere. If there’s a pending exec approval, the install may be waiting for that; don’t invent an /approve command manually unless OpenClaw shows you the exact one.

Relevant docs while we narrow it down:
https://docs.openclaw.ai/help/faq
https://docs.openclaw.ai/gateway/troubleshooting
https://docs.openclaw.ai/tools/exec-approvals

Paste the version + the log lines around [assistant turn failed before producing content] and I’ll help decode it. 🦞

broken otter May 10, 2026, 8:11 AM

#

openclaw --version
OpenClaw 2026.5.6 (c97b9f7)

Log file: /tmp/openclaw/openclaw-2026-05-10.log
07:59:42+00:00 warn diagnostic {"subsystem":"diagnostic"} long-running session: sessionId=96102969-944d-4cfb-98b1-3a8b17ff6bdc sessionKey=agent:main:main state=processing age=136s queueDepth=1 reason=queued_behind_active_work classification=long_running activeWorkKind=model_call lastProgress=model_call:started lastProgressAge=22s recovery=none
08:00:14+00:00 warn agent/embedded {"subsystem":"agent/embedded"} {"event":"embedded_run_failover_decision","tags":["error_handling","failover","assistant","surface_error"],"runId":"80aaa24a-a65f-40b4-84ed-0531f77ba963","stage":"assistant","decision":"surface_error","failoverReason":"timeout","profileFailureReason":"timeout","provider":"ollama","model":"qwen3-coder:30b","sourceProvider":"ollama","sourceModel":"qwen3-coder:30b","profileId":"sha256:9c018ec112cf","fallbackConfigured":false,"timedOut":true,"aborted":true} embedded run failover decision
08:10:40+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✗ system-presence 4ms errorCode=INVALID_REQUEST errorMessage=missing scope: operator.read conn=30e4512f…75d3 id=41c5228d…81ed
08:10:40+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ channels.status 147ms conn=b197cc72…4c77 id=8c375e05…cec8
08:10:41+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ health 109ms conn=495c18fe…8c9e id=20d4d921…69dd
08:10:44+00:00 info gateway {"subsystem":"gateway"} device pairing auto-approved device=d60c8ef6bd10bbde2ebd45b532a5cdc88bebba8d0f299ec1156ca252bb44d964 role=operator

modest vectorBOT May 10, 2026, 8:11 AM

#

Yep, the smoking gun is here:

provider="ollama", model="qwen3-coder:30b"
failoverReason="timeout"
fallbackConfigured=false
timedOut=true

So the agent isn’t stuck on Apache specifically — your local Ollama model timed out during the model call, and there’s no fallback configured. The “connected | idle” UI can look misleading after that because the Gateway is alive, but the active agent turn died/timed out.

What I’d do next:

Restart to clear the wedged turn:

openclaw gateway restart

#

Switch to a stronger/hosted tool-reliable model, or configure a fallback. For Apache/server setup tasks, local Ollama coder models often stall or fail tool-use under real agent workloads.

Helpful checks:

openclaw models status
openclaw models list
openclaw onboard

Docs:
https://docs.openclaw.ai/concepts/models
https://docs.openclaw.ai/help/faq

The missing scope: operator.read line is probably the dashboard/operator connection needing a refreshed pairing/scope, but it’s not the main cause of this failure. The main cause is the Ollama timeout with no fallback.

broken otter May 10, 2026, 8:14 AM

#

pavle@openclaw:~$ openclaw models status
openclaw models list
openclaw onboard

🦞 OpenClaw 2026.5.6 (c97b9f7) — I can run local, remote, or purely on vibes—results may vary with DNS.

Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/main/agent
Default : ollama/qwen3-coder:30b
Fallbacks (0) : -
Image model : -
Image fallbacks (0): -
Aliases (0) : -
Configured models (4): ollama/glm-4.7-flash:latest, openai/to qwen3-coder, ollama/qwen3-coder, ollama/qwen3-coder:30b

Auth overview
Auth store : ~/.openclaw/agents/main/agent/auth-profiles.json
Shell env : off
Providers w/ OAuth/tokens (0): -

ollama effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | ollama:default=marker(ollama-local) | models.json=OL...EY | source=models.json: ~/.openclaw/agents/main/agent/models.json | synthetic=plugin-owned | source=models.providers.ollama (synthetic local key)

OAuth/token status

none

🦞 OpenClaw 2026.5.6 (c97b9f7) — I run on caffeine, JSON5, and the audacity of "it worked on my machine."

Model Input Ctx Local Auth Tags
ollama/qwen3-coder:30b text 256k no yes default,configured
ollama/glm-4.7-flash:latest text 198k no yes configured
openai/to qwen3-coder text 195k no no configured
ollama/qwen3-coder text 195k no yes configured

modest vectorBOT May 10, 2026, 8:15 AM

#

That confirms it: your install is configured to use only local Ollama, with:

Default: ollama/qwen3-coder:30b
Fallbacks: none
Providers w/ OAuth/tokens: none

So when qwen3-coder:30b times out, OpenClaw has nowhere else to go and the turn fails. For tool-heavy admin work like installing Apache, local Ollama models can be pretty fragile.

Two practical fixes:

Option A — recommended: run onboarding and add a hosted/tool-reliable provider as default or fallback:

openclaw onboard

#

openclaw gateway restart

Then check:

openclaw models status

You want to see at least one fallback, or a default that is not the Ollama model that’s timing out.

Option B — stay local: use a smaller/faster local model and add a fallback, but expect tool-use reliability to still be mixed. Also, that configured entry looks suspicious:

openai/to qwen3-coder

#

That doesn’t look like a valid model ref and is worth removing/cleaning during onboarding/config.

For current model recommendations, ask in #models because that changes fast. Docs are here: https://docs.openclaw.ai/concepts/models

After changing the model config, restart the gateway and try a smaller first task like:

check if apache is installed; do not install yet

If that works, then ask it to install Apache and watch for the approval prompt.

broken otter May 10, 2026, 8:29 AM

#

now the agent doesnt run commands
Please copy and paste these commands into your terminal one by one, entering the sudo password my_password when prompted.
If you need further assistance or have any issues, feel free to let me know!

modest vectorBOT May 10, 2026, 8:30 AM

#

Two things here:

Don’t put your sudo password in prompts or Discord. If that was your real password, rotate it. The agent should not ask you to paste a password into chat.
This usually means one of these is true:
- the model is still not reliably using tools, so it falls back to “you run it manually”
- exec/runtime tools are blocked by tool policy
- root/elevated execution isn’t available, so it can’t install packages itself

Please run:

openclaw config get tools.profile
openclaw config get tools.allow
openclaw config get tools.deny
openclaw config get tools.exec.host

#

openclaw config get tools.exec.security
openclaw config get tools.exec.ask
openclaw sandbox explain

If you want it to actually run shell commands from chat, tools.profile should generally be coding or full, or tools.allow needs group:runtime / exec. Docs: https://docs.openclaw.ai/gateway/config-tools

For installing Apache specifically, the clean safe pattern is: ask it to check the system first, then approve/handle root separately. Try:

Run: whoami; pwd; command -v apache2 || true. Do not install anything yet.

If it still gives copy/paste instructions instead of running even harmless commands, that’s a tool/model routing issue — and I’d switch off the local Ollama model before debugging Apache further.

broken otter May 10, 2026, 8:31 AM

#

openclaw config get tools.profile
openclaw config get tools.allow
openclaw config get tools.deny
openclaw config get tools.exec.host

🦞 OpenClaw 2026.5.6 (c97b9f7) — Making 'I'll automate that later' happen now.

coding

🦞 OpenClaw 2026.5.6 (c97b9f7) — I don't judge, but your missing API keys are absolutely judging you.

Config path not found: tools.allow

🦞 OpenClaw 2026.5.6 (c97b9f7) — If you can describe it, I can probably automate it—or at least make it funnier.

Config path not found: tools.deny

🦞 OpenClaw 2026.5.6 (c97b9f7) — We ship features faster than Apple ships calculator updates.

Config path not found: tools.exec.host

modest vectorBOT May 10, 2026, 8:31 AM

#

Good — this means tool policy is fine. tools.profile=coding includes exec, and the missing tools.allow/deny/exec.host just means you’re using defaults.

So the remaining likely cause is the model, not config: the local ollama/qwen3-coder:30b is either timing out or choosing not to call tools.

Try these as standalone messages to your agent:

/tools verbose

then:

Run exactly this harmless shell command using the exec tool: whoami && pwd && uname -a

If /tools shows exec but the agent still replies with “copy/paste this into your terminal”, that’s model/tool-use failure. Switch to a stronger hosted model or add one as a fallback via:

#

openclaw onboard
openclaw gateway restart

For Apache install: even once exec works, sudo apt install ... may still need human approval/password handling. Don’t paste passwords into chat; either approve the native exec prompt if OpenClaw shows one, or run the sudo install manually.

broken otter May 10, 2026, 8:38 AM

#

Understood. I'll guide you through the process of installing Apache on your system using the commands you need to run in your terminal. Since I can't execute these commands directly, please follow the steps below:

why does the agent say this when i say it to execute commands?

modest vectorBOT May 10, 2026, 8:38 AM

#

Because the model is deciding not to call the exec tool.

Your config says tools should be available (tools.profile = coding), so when it says “Since I can’t execute commands directly…”, that’s usually one of these:

the active model (ollama/qwen3-coder:30b) is bad at OpenClaw tool calling / timed out earlier
the current session got into a weird state after the failed run
exec is available, but the model is being cautious because Apache install needs sudo

Do this in the same chat with your agent:

/tools verbose

If exec is listed, then send:

#

Use the exec tool now. Run only this harmless command: whoami && pwd && uname -a

If it still gives instructions instead of running the command, reset the session and switch models:

/reset

Then configure a stronger hosted/tool-reliable model or fallback:

openclaw onboard
openclaw gateway restart

#

The key point: tools.profile=coding means OpenClaw is allowed to run commands, but local Ollama models often don’t reliably choose the tool. That’s why it’s acting like ChatGPT instead of an agent.

broken otter May 10, 2026, 8:42 AM

#

in the tool verbose command exec is not listed

modest vectorBOT May 10, 2026, 8:43 AM

#

Ah, that changes it — if exec is not listed in /tools verbose, then the agent really cannot run shell commands in that session. It’s not just the model refusing.

Since global tools.profile is coding, something more specific is overriding/removing it. Check these:

openclaw config get agents.list
openclaw config get tools.byProvider
openclaw config get agents.defaults.tools
openclaw sandbox explain
openclaw doctor

Look especially for any tools.allow, tools.deny, profile: "minimal", or provider-specific policy under ollama / ollama/qwen3-coder:30b.

Quick fix to try, if you’re okay with the main agent having command tools:

#

openclaw config set tools.profile coding
openclaw gateway restart

Then in chat run:

/reset
/tools verbose

If exec still isn’t there, paste the output of agents.list + tools.byProvider here. That’ll show what’s hiding the runtime tools. Docs: https://docs.openclaw.ai/gateway/config-tools

broken otter May 10, 2026, 8:46 AM

#

how to simply allow the agent to run commands?

modest vectorBOT May 10, 2026, 8:46 AM

#

Simplest version:

openclaw config set tools.profile coding
openclaw config unset tools.allow
openclaw config unset tools.deny
openclaw config unset tools.byProvider
openclaw gateway restart

Then in the agent chat:

/reset
/tools verbose

#

You should see exec listed.

If exec is still not listed, a per-agent override is probably blocking it. Then paste this output before changing more:

openclaw config get agents.list --json

The setting that allows command execution is tools.profile: coding because coding includes group:runtime, which includes exec + process.

Docs: https://docs.openclaw.ai/gateway/config-tools

broken otter May 10, 2026, 8:47 AM

#

Config path not found: tools.allow

Config path not found: tools.deny

Config path not found: tools.byProvider

Config path not found: agents.list

modest vectorBOT May 10, 2026, 8:48 AM

#

Those “Config path not found” messages are fine — they mean there are no overrides blocking tools there.

To simply allow command execution globally, run:

openclaw config set tools.profile coding
openclaw config set tools.exec.host gateway
openclaw config set tools.exec.security full
openclaw config set tools.exec.ask off
openclaw gateway restart

Then in the agent chat:

/reset

#

/tools verbose

exec should show up.

If exec still does not show up, the likely issue is your Ollama model entry is marked as not supporting tools. Check with:

openclaw config get models.providers.ollama --json

Look for something like:

"compat": { "supportsTools": false }

#

If that exists, OpenClaw intentionally hides tools from that model. Easiest fix: run model onboarding and pick a tool-capable model/provider:

openclaw onboard
openclaw gateway restart

Docs for the exact knobs: https://docs.openclaw.ai/gateway/config-tools and https://docs.openclaw.ai/providers/ollama

broken otter May 10, 2026, 8:51 AM

#

Hello, can you install apache2 webserver on this local machine

{"name": "exec", "arguments": {"command": "sudo apt-get update && sudo apt-get install -y apache2"}}

nothing actually happened on the server

modest vectorBOT May 10, 2026, 8:52 AM

#

That JSON was not an actual tool call — the model printed text that looks like a tool call:

{"name":"exec","arguments":{...}}

OpenClaw only runs commands when the model emits a real structured tool call internally. If you see raw JSON in the chat, nothing executed.

This points back to the model/provider setup, especially with Ollama. Common causes:

the Ollama model doesn’t actually support tool calling well
the model entry has compat.supportsTools: false
Ollama is configured through the /v1 OpenAI-compatible URL instead of native Ollama API
the local model is too weak/unstable for tool use

Check this:

#

openclaw config get models.providers.ollama --json

Look for:

"baseUrl": "http://127.0.0.1:11434/v1"

If you see /v1, fix it to native Ollama:

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

#

Also look for:

"compat": { "supportsTools": false }

If that’s present, OpenClaw is intentionally not giving tools to that model.

Honestly, for “install apache on my server”, I’d use a stronger hosted/tool-reliable model or configure one as fallback via:

openclaw onboard
openclaw gateway restart

Then test with a harmless command first:

#

Run this with exec: whoami && pwd

Only after that works, try Apache. And don’t paste sudo passwords into chat — if sudo needs approval/password, handle that via the native approval prompt or manually in terminal.

broken otter May 10, 2026, 8:53 AM

#

how to change ollama model that is usedi n openclaw

modest vectorBOT May 10, 2026, 8:53 AM

#

Use openclaw models set.

First list the Ollama models OpenClaw sees:

openclaw models list --provider ollama

Then set one as the default, for example from your earlier list:

openclaw models set ollama/glm-4.7-flash:latest
openclaw gateway restart

Or if you want to switch back:

#

openclaw models set ollama/qwen3-coder:30b
openclaw gateway restart

Then verify:

openclaw models status

In the chat with your agent, start fresh after changing it:

/reset
/tools verbose

#

Docs: https://docs.openclaw.ai/cli/models and https://docs.openclaw.ai/providers/ollama

broken otter May 10, 2026, 8:59 AM

#

Hello, can you assizst me by creating an apache2 webserver on this local machine. Run all needed commands

response:
ll help you set up an Apache2 webserver on this local machine. Let me install and configure it for you.Apache2 has been installed successfully. Now let me start the service and verify it's running:Now let me create a test page and check if the webserver is accessible:
after 2 mins it just said

This response is taking longer than expected. Send another message to continue.

modest vectorBOT May 10, 2026, 9:00 AM

#

That message means the turn didn’t finish before the chat timeout. The work may still be running, or it may be stuck on something like sudo, apt, or systemctl.

First check the agent state from the same chat:

/status

If it says something is still processing, send:

continue

If it looks idle or failed, check the server directly:

#

systemctl status apache2 --no-pager
sudo journalctl -u apache2 -n 50 --no-pager
openclaw logs --follow

Also verify whether Apache actually installed:

command -v apache2 || true
systemctl is-active apache2 || true
curl -I http://127.0.0.1 || true

If the model said “installed successfully” without showing real command output, be suspicious — local Ollama models can hallucinate tool progress. The reliable sign is actual exec output in the transcript or the server checks above.

broken otter May 10, 2026, 9:17 AM

#

prompt: Now in that document root for the apache2 server make a little cool site for my CV. I want professional blue design. I am an sys administrator and i have a homelab.
response: Now I'll create a professional, modern CV website for you with a blue theme targeting your sysadmin/homelab background:

then This response is taking longer than expected. Send another message to continue.

I typed Continue then
run abored

also 0 gpu usage on my ollama server. why is this the case

modest vectorBOT May 10, 2026, 9:17 AM

#

0 GPU usage means OpenClaw probably wasn’t actively generating on Ollama at that moment, or Ollama is running the model on CPU / failed before generation.

Given your earlier logs showed:

provider="ollama" model="qwen3-coder:30b" failoverReason="timeout" timedOut=true

what’s likely happening is:

the agent starts a turn
it either gets stuck before/around the model call, or the model call times out
Discord shows “taking longer than expected”
“continue” arrives after the run is already aborted, so nothing resumes
Ollama never does real GPU work, or it only did a tiny burst you missed

Check these while a run is happening:

#

openclaw logs --follow
ollama ps
watch -n 1 nvidia-smi

Also test Ollama directly outside OpenClaw:

ollama run qwen3-coder:30b "write a tiny blue HTML CV page for a sysadmin homelab owner"

If direct Ollama also shows 0 GPU, then it’s an Ollama/GPU offload issue, not OpenClaw. If direct Ollama uses GPU but OpenClaw doesn’t, paste the OpenClaw log lines around the aborted run.

For the CV site task, avoid making the local model do sudo + file writes + long generation in one turn. Try smaller steps:

#

First run pwd and identify the Apache document root. Do not edit files yet.

Then:

Create one simple /var/www/html/index.html CV page. Keep it under 150 lines. Use exec or write tools, and show the exact file path changed.

But honestly: if you want this to be smooth, switch to a stronger tool-reliable hosted model/fallback. Local Ollama can work, but this exact behavior — raw tool JSON, fake progress, timeouts, aborted continues — is classic weak/local tool-calling failure.

broken otter May 10, 2026, 9:20 AM

#

09:01:04+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ sessions.list 252ms conn=a79c27af…7089 id=e0e17631…20de
09:01:04+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✗ sessions.resolve 1ms errorCode=INVALID_REQUEST errorMessage=No session found: current conn=443544ea…e137 id=122a2583…e556
09:01:04+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✗ sessions.resolve 1ms errorCode=INVALID_REQUEST errorMessage=No session found: current conn=def176fc…b18e id=7f47f1d6…80bc
09:15:11+00:00 warn agent/embedded {"subsystem":"agent/embedded"} {"event":"embedded_run_failover_decision","tags":["error_handling","failover","assistant","surface_error"],"runId":"0132b739-0fe2-4078-99c7-f7ced3705aaf","stage":"assistant","decision":"surface_error","failoverReason":"timeout","profileFailureReason":"timeout","provider":"ollama","model":"glm-4.7-flash:latest","sourceProvider":"ollama","sourceModel":"glm-4.7-flash:latest","profileId":"sha256:9c018ec112cf","fallbackConfigured":false,"timedOut":true,"aborted":true} embedded run failover decision
09:20:12+00:00 warn fetch-timeout {"subsystem":"fetch-timeout"} {"timeoutMs":300000,"elapsedMs":300000,"operation":"fetchWithSsrFGuard","url":"http://192.168.1.231:11434/api/chat"} fetch timeout reached; aborting operation
09:20:12+00:00 warn agent/embedded {"subsystem":"agent/embedded"} Profile ollama:default timed out. Trying next account...
09:20:12+00:00 warn agent/embedded {"subsystem":"agent/embedded"} [llm-idle-timeout] ollama/glm-4.7-flash:latest produced no reply before the idle watchdog; retrying same model

modest vectorBOT May 10, 2026, 9:20 AM

#

These logs confirm the problem pretty clearly: OpenClaw is reaching your Ollama server, but Ollama does not return any chat response for 5 minutes.

fetch timeout reached ... url="http://192.168.1.231:11434/api/chat"
ollama/glm-4.7-flash:latest produced no reply before the idle watchdog

So this is not Apache, Discord, or /continue — the model backend is hanging/timing out.

Check from the OpenClaw machine:

curl http://192.168.1.231:11434/api/tags
curl -N http://192.168.1.231:11434/api/chat \
  -H 'Content-Type: application/json' \
  -d '{"model":"glm-4.7-flash:latest","messages":[{"role":"user","content":"Say hello in one sentence"}],"stream":true}'

#

And on the Ollama server while that runs:

ollama ps
nvidia-smi
journalctl -u ollama -n 100 --no-pager

If the direct curl /api/chat also hangs or uses 0 GPU, fix Ollama/GPU first. Common causes:

model is too large / running on CPU
Ollama service can’t see CUDA/GPU
model is stuck loading/unloading
remote Ollama host is slow/unreachable under load

For OpenClaw, you can also raise the Ollama timeout, but that only masks slowness:

#Agent stops working