Everything new - not working | Friends of the Crustacean 🦞🤝 | Page 1

manic flare Apr 18, 2026, 7:17 PM

#

I'm looking at exploring openclaw, and am very new to it. I have a mini pc running a fresh install of Ubuntu (pc specs are good - ryzen5 7640HS - 32GB DDR5.) I will be running gemma4 locally. I installed ollama, and set it up. Pulled the model, and ran a test chat, everything good. I then installed OpenClaw, set the model to ollama and selected local only. Base url default 127.0.0.1:11434 'Skip for now' to the rest. When I went with the recommendation of 'Hatch in TUI' the system sends "Wake up, my friend!" but then the response hangs.
I haven't played with linux in over 15 years, so I'm still relearning a lot of this. Does anyone know what I may be missing here to get this to respond?
I did also try to launch the agent in the browser UI, but got the same lingering hang after sending a prompt.

swift jayBOT Apr 18, 2026, 7:17 PM

#

chilly geyserBOT Apr 18, 2026, 7:17 PM

#

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

swift jayBOT Apr 18, 2026, 7:17 PM

#

void solarBOT Apr 18, 2026, 7:19 PM

#

You’re probably close. Since it hangs in both TUI and browser UI, this looks more like the OpenClaw ↔ Ollama runtime path than the UI itself.

The docs have a specific note for this exact symptom: if you see “Wake up, my friend!” with no reply, the agent usually never actually ran.

Can you paste the output of these?

openclaw --version
openclaw status
openclaw gateway status
openclaw models status
openclaw doctor
openclaw infer model run --model ollama/gemma4 --prompt "Say hi in one short sentence." --json

Then in another terminal, run:

#

openclaw logs --follow

Two quick checks meanwhile:

Make sure the Ollama URL is http://127.0.0.1:11434, with no /v1
A plain Ollama chat working does not always mean OpenClaw will work, because the first agent turn is a much heavier prompt than a simple ollama run

If that infer model run works, the next suspect is the full agent prompt/tool surface, which some local Gemma/Ollama setups struggle with.

Docs:
https://docs.openclaw.ai/help/faq
https://docs.openclaw.ai/help/troubleshooting
https://docs.openclaw.ai/providers/ollama
https://docs.openclaw.ai/gateway/local-models

manic flare Apr 18, 2026, 7:43 PM

#

michael@AInchor:~$ openclaw --version
OpenClaw 2026.4.15 (041266a)

#

michael@AInchor:~$ openclaw status

🦞 OpenClaw 2026.4.15 (041266a)
If you're lost, run doctor; if you're brave, run prod; if you're wise, run tests.

│
◇
│
◇
OpenClaw status

#

│ OS │ linux 6.17.0-20-generic (x64) · node 22.22.2 │
│ Dashboard │ http://127.0.0.1:18789/ │
│ Tailscale │ off │
│ Channel │ stable (default) │
│ Update │ pnpm · up to date · npm latest 2026.4.15 │
│ Gateway │ local · ws://127.0.0.1:18789 (local loopback) · │
│ │ reachable 36ms · auth token · AInchor (192.168.1.5) │
│ │ app 2026.4.15 linux 6.17.0-20-generic │
│ Gateway self │ AInchor (192.168.1.5) app 2026.4.15 linux 6.17.0-20- │
│ │ generic │
│ Gateway service │ systemd installed · enabled · running (pid 36704, │
│ │ state active) │
│ Node service │ systemd not installed │
│ Agents │ 1 · 1 bootstrap file present · sessions 1 · default │
│ │ main active 27m ago │
│ Memory │ enabled (plugin memory-core) · unavailable │
│ Plugin compatibility │ none │
│ Probes │ skipped (use --deep) │
│ Events │ none │
│ Tasks │ none │
│ Heartbeat │ 30m (main) │
│ Sessions │ 1 active · default gemma4 (128k ctx) · ~/.openclaw/ │
│ │ agents/main/sessions/sessions.json │
└──────────────────────┴──────────────────────

void solarBOT Apr 18, 2026, 7:43 PM

#

Nice, that version is recent enough, so this probably is not a stale-version bug.

Next, can you paste these?

openclaw status
openclaw gateway status
openclaw models status
openclaw doctor
ollama list

Then this one, which isolates model access from the full agent runtime:

openclaw infer model run --model ollama/gemma4 --prompt "Say hi in one short sentence." --json

#

And in a second terminal, keep this running while you retry Hatch:

openclaw logs --follow

I’m mainly trying to answer 2 questions:

Is the Gateway healthy?
Can OpenClaw talk to Ollama directly, outside the full agent bootstrap?

If infer model run works but Hatch still hangs, that points pretty strongly at the heavier agent prompt/tool surface, not basic Ollama connectivity.

manic flare Apr 18, 2026, 7:44 PM

#

Security audit
Summary: 0 critical · 4 warn · 1 info
WARN Reverse proxy headers are not trusted
gateway.bind is loopback and gateway.trustedProxies is empty. If you expose the Control UI through a reverse proxy, configure trusted proxies so local-client c…
Fix: Set gateway.trustedProxies to your proxy IPs or keep the Control UI local-only.
WARN Control UI insecure auth toggle enabled
gateway.controlUi.allowInsecureAuth=true does not bypass secure context or device identity checks; only dangerouslyDisableDeviceAuth disables Control UI device…
Fix: Disable it or switch to HTTPS (Tailscale Serve) or localhost.
WARN Insecure or dangerous config flags enabled
Detected 1 enabled flag(s): gateway.controlUi.allowInsecureAuth=true.
Fix: Disable these flags when not actively debugging, or keep deployment scoped to trusted/local-only networks.
WARN Some gateway.nodes.denyCommands entries are ineffective
gateway.nodes.denyCommands uses exact node command-name matching only (for example system.run), not shell-text filtering inside a command payload. - Unknown …
Fix: Use exact command names (for example: canvas.present, canvas.hide, canvas.navigate, canvas.eval, canvas.snapshot, canvas.a2ui.push, canvas.a2ui.pushJSONL, canvas.a2ui.reset). If you need broader restrictions, remove risky command IDs from allowCommands/default workflows and tighten tools.exec policy.
Full report: openclaw security audit
Deep probe: openclaw security audit --deep

#

Channels
┌──────────┬─────────┬────────┬────────────────────────────────────────────────┐
│ Channel │ Enabled │ State │ Detail │
├──────────┼─────────┼────────┼────────────────────────────────────────────────┤
└──────────┴─────────┴────────┴────────────────────────────────────────────────┘

Sessions
┌────────────────────────┬────────┬─────────┬──────────────┬───────────────────┐
│ Key │ Kind │ Age │ Model │ Tokens │
├────────────────────────┼────────┼─────────┼──────────────┼───────────────────┤
│ agent:main:main │ direct │ 27m ago │ gemma4 │ unknown/128k (?%) │
└────────────────────────┴────────┴─────────┴──────────────┴───────────────────┘

FAQ: https://docs.openclaw.ai/faq
Troubleshooting: https://docs.openclaw.ai/troubleshooting
Next steps:
Need to share? openclaw status --all
Need to debug live? openclaw logs --follow
Need to test channels? openclaw status --deep

void solarBOT Apr 18, 2026, 7:44 PM

#

That output is actually useful. openclaw status should print a real report, so if it stops at “OpenClaw status” or keeps spinning, that points back to the Gateway/probe path.

A couple quick questions:

Does your shell prompt come back after that, or does it just sit there?
Can you run these next and paste the output?

openclaw gateway probe
openclaw gateway status
openclaw doctor
openclaw infer model run --model ollama/gemma4 --prompt "Say hi in one short sentence." --json

Then in another terminal:

#

openclaw logs --follow

Retry Hatch once while logs --follow is running, then paste the first error-looking lines.

At this point I’m trying to separate:

Gateway health problem
OpenClaw → Ollama connection problem
Gemma handling small direct prompts fine, but choking on the full agent bootstrap prompt

manic flare Apr 18, 2026, 7:45 PM

#

michael@AInchor:~$ openclaw gateway status

🦞 OpenClaw 2026.4.15 (041266a)
I speak fluent bash, mild sarcasm, and aggressive tab-completion energy.

│
◇
Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-04-18.log
Command: /usr/bin/node /home/michael/.npm-global/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/.config/systemd/user/openclaw-gateway.service
Service env: OPENCLAW_GATEWAY_PORT=18789

Config (cli): ~/.openclaw/openclaw.json
Config (service): ~/.openclaw/openclaw.json

Gateway: bind=loopback (127.0.0.1), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/
Probe note: Loopback-only gateway; only local clients can connect.

Runtime: running (pid 36704, state active, sub running, last exit 0, reason 0)
RPC probe: ok

Listening: 127.0.0.1:18789
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting

#

michael@AInchor:~$ openclaw models status

🦞 OpenClaw 2026.4.15 (041266a)
I'm not AI-powered, I'm AI-possessed. Big difference.

Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/main/agent
Default : ollama/gemma4
Fallbacks (0) : -
Image model : -
Image fallbacks (0): -
Aliases (0) : -
Configured models (0): all

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

OAuth/token status

none

void solarBOT Apr 18, 2026, 7:45 PM

#

This is good news. Your Gateway looks healthy.

The big clues here are:

Gateway is reachable
systemd service is running
session exists and the default model is gemma4
1 bootstrap file present means the first-run bootstrap ritual has not finished yet, which fits the “Wake up, my friend!” hang

So I would stop chasing connectivity for now. The more likely issue is that the local model is stalling on the heavier bootstrap prompt.

Can you run these next?

openclaw doctor
openclaw infer model run --model ollama/gemma4 --prompt "Say hi in one short sentence." --json

#

Then in another terminal:

openclaw logs --follow

Retry Hatch once while the logs are open, then paste the first error-looking lines.

Important: I would not manually delete BOOTSTRAP.md yet. Right now it just tells us bootstrap never completed. If the small direct infer model run works but Hatch still hangs, then we’re very likely looking at a Gemma/OpenClaw prompt-shape issue, not a broken install.

#

Easy mix-up, that output is from openclaw security audit, not openclaw doctor 🙂

Those warnings are useful, but they are not what’s causing Hatch to hang. I wouldn’t change any of that yet.

The two things I still really need are:

openclaw doctor
openclaw infer model run --model ollama/gemma4 --prompt "Say hi in one short sentence." --json

And in another terminal:

openclaw logs --follow

#

Then retry Hatch once and paste:

the output of infer model run
the first error-looking lines from logs --follow

That should tell us pretty quickly whether this is:

a direct OpenClaw → Ollama failure, or
Gemma handling small chats fine, but stalling on the larger bootstrap prompt.

#

You’re not doing anything wrong, we’re just narrowing it down one layer at a time.

This latest output confirms the session exists, but the one test I still need is whether OpenClaw can call the model directly, outside the TUI.

Please run exactly this next:

openclaw infer model run --model ollama/gemma4 --prompt "Say hi in one short sentence." --json

Then paste whatever it does, even if it just hangs or errors.

If it hangs for more than about a minute, say that too. That result is the key one.

#

Perfect, that confirms the gateway itself is healthy.

So now let’s bypass the TUI and do the simplest possible model test. This one is nice because it uses the normal local path and does not depend on the chat UI:

openclaw infer model run --prompt "Reply with exactly: smoke-ok" --json

Please paste whatever it prints.

If it hangs, say “it hangs” and about how long you waited. If it works, we’ve narrowed this down to the bootstrap/chat path rather than basic model execution.

manic flare Apr 18, 2026, 7:47 PM

#

michael@AInchor:~$ openclaw doctor

🦞 OpenClaw 2026.4.15 (041266a)
I run on caffeine, JSON5, and the audacity of "it worked on my machine."

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

┌ OpenClaw doctor
│
◇ Update ───────────────────────────────────────────────────────────────╮
│ │
│ This install is not a git checkout. │
│ Run openclaw update to update via your package manager (npm/pnpm), │
│ then rerun doctor. │
│ │
├────────────────────────────────────────────────────────────────────────╯
│

#

◇ State integrity ────────────────────────────────────────────────────────────╮
│ │
│ - OAuth dir not present (~/.openclaw/credentials). Skipping create │
│ because no WhatsApp/pairing channel config is active. │
│ - 1/1 recent sessions are missing transcripts. │
│ Verify sessions in store: openclaw sessions --store │
│ "/home/michael/.openclaw/agents/main/sessions/sessions.json" │
│ Preview cleanup impact: openclaw sessions cleanup --store │
│ "/home/michael/.openclaw/agents/main/sessions/sessions.json" │
│ --dry-run │
│ Prune missing entries: openclaw sessions cleanup --store │
│ "/home/michael/.openclaw/agents/main/sessions/sessions.json" │
│ --enforce --fix-missing │
│ - Main session transcript missing │
│ (~/.openclaw/agents/main/sessions/375d2f1e-6ebc-4d5c-959b-d7256f010c40.j │
│ sonl). │
│ History will appear to reset.

#

◇ Security ─────────────────────────────────╮
│ │
│ - No channel security warnings detected. │
│ - Run: openclaw security audit --deep │
│ │
├────────────────────────────────────────────╯
│
◇ Skills status ────────────╮
│ │
│ Eligible: 6 │
│ Missing requirements: 46 │
│ Blocked by allowlist: 0 │
│ │
├────────────────────────────╯
│
◇ Plugins ──────╮
│ │
│ Loaded: 57 │
│ Imported: 57 │
│ Disabled:

#

41 │
│ Errors: 0 │
│ │
├────────────────╯
│
◇ Enable bash shell completion for openclaw?
│ Yes
│
◇ Shell completion ──────────────────────────────────────────────╮
│ │
│ Shell completion installed. Restart your shell or run: source │
│ ~/.bashrc │
│ │
├─────────────────────────────────────────────────────────────────╯
│
◇
Agents: main (default)
Heartbeat interval: 30m (main)
Session store (main): /home/michael/.openclaw/agents/main/sessions/sessions.json (1 entries)

agent:main:main (30m ago)

void solarBOT Apr 18, 2026, 7:48 PM

#

Honestly, everything you’ve pasted so far looks basically correct.

So I don’t think you’re missing some obvious install step anymore. OpenClaw sees:

ollama/gemma4 as the default model
a valid local Ollama auth marker
a healthy local gateway

That makes me think this is most likely a local model prompt-shape issue, not a broken setup. Plain Ollama chat can work, while OpenClaw’s first bootstrap turn is still too much for the model/runtime.

If you want to try the most likely fix now, I’d do this:

openclaw config set agents.defaults.experimental.localModelLean true
openclaw gateway restart

#

Then try Hatch again.

That flag is specifically documented as a pressure-release valve for smaller/stricter local backends. It trims heavyweight default tools so the prompt is smaller.

Docs:
https://docs.openclaw.ai/gateway/local-models
https://docs.openclaw.ai/concepts/experimental-features

If that still hangs, I’d test with a stronger model or a temporary cloud model just to confirm the rest of your install is fine.

#

Yep, that Doctor output is not the problem. It’s basically just an update note, not a blocker.

At this point, with:

gateway healthy
model resolved to ollama/gemma4
local auth present

…I’d stop digging and try the likely fix:

openclaw config set agents.defaults.experimental.localModelLean true
openclaw gateway restart

Then Hatch again.

#

Why this one: the docs call localModelLean a pressure-release valve for local backends that choke on OpenClaw’s full default prompt/tool surface, which is exactly what this looks like.

If it still hangs after that, then I’d test with a stronger model or a temporary cloud model just to prove the rest of the install is fine.

Docs:
https://docs.openclaw.ai/gateway/local-models
https://docs.openclaw.ai/concepts/experimental-features

manic flare Apr 18, 2026, 7:49 PM

#

◇ Memory search ──────────────────────────────────────────────────────────╮
│ │
│ Memory search is enabled, but no embedding provider is ready. │
│ Semantic recall needs at least one embedding provider. │
│ Gateway memory probe for default agent is not ready: No GitHub token │
│ available for Copilot embedding provider │
│ │
│ No API key found for provider "openai". Auth store: │
│ /home/michael/.openclaw/agents/main/agent/auth-profiles.json │
│ (agentDir: /home/michael/.openclaw/agents/main/agent). Configure auth │
│ for this agent (openclaw agents add <id>) or copy auth-profiles.json │
│ from the main agentDir. │
│ │
│ No API key found for provider "google". Auth store: │
│ /home/michael/.openclaw/agents/main/agent/auth-profiles.json │
│ (agentDir: /home/michael/.openclaw/agents/main/agent). Configure auth │
│ for this agent (openclaw agents add <id>) or copy auth-profiles.json │
│ from the main agentDir.

#

No API key found for provider "voyage". Auth store: │
│ /home/michael/.openclaw/agents/main/agent/auth-profiles.json │
│ (agentDir: /home/michael/.openclaw/agents/main/agent). Configure auth │
│ for this agent (openclaw agents add <id>) or copy auth-profiles.json │
│ from the main agentDir. │
│ │
│ No API key found for provider "mistral". Auth store: │
│ /home/michael/.openclaw/agents/main/agent/auth-profiles.json │
│ (agentDir: /home/michael/.openclaw/agents/main/agent). Configure auth │
│ for this agent (openclaw agents add <id>) or copy auth-profiles.json │
│ from the main agentDir. │
│ │
│ Fix (pick one): │
│ - Set OPENAI_API_KEY, GEMINI_API_KEY, GOOGLE_API_KEY, VOYAGE_API_KEY, │
│ MISTRAL_API_KEY in your environment │
│ - Configure credentials: openclaw configure --section model │
│ - For local embeddings: configure │
│ agents.defaults.memorySearch.provider and local model path │
│ - To disable: openclaw config set agents.defaults.memorySearch.enabled │
│ false │
│ │
│ Verify: openclaw memory status --deep

#

Run "openclaw doctor --fix" to apply changes.
│
└ Doctor complete.

michael@AInchor:~$ openclaw infer model run --model ollama/gemma4 --prompt "Say hi in one short sentence." --json
15:29:57 [agent/embedded] Profile ollama:default timed out. Trying next account...
15:29:57 [agent/embedded] [llm-idle-timeout] ollama/gemma4 produced no reply before the idle watchdog; retrying same model
15:31:58 [agent/embedded] Profile ollama:default timed out. Trying next account...
15:31:58 [agent/embedded] embedded run failover decision: runId=375d2f1e-6ebc-4d5c-959b-d7256f010c40 stage=assistant decision=surface_error reason=timeout from=ollama/gemma4 profile=sha256:9c018ec112cf
{
"ok": true,
"capability": "model.run",
"transport": "local",
"provider": "ollama",
"model": "gemma4",
"attempts": [],
"outputs": [
{
"text": "The model did not produce a response before the LLM idle timeout. Please try again, or increase agents.defaults.llm.idleTimeoutSeconds in your config (set to 0 to disable).",
"mediaUrl": null
}
]
}
michael@AInchor:~$

void solarBOT Apr 18, 2026, 7:50 PM

#

Ah, this is the first concrete problem we’ve found.

The important line is:

Main session transcript missing
1/1 recent sessions are missing transcripts

That means the active session state is out of sync. I’d try this in order:

Start a fresh session with /new as a standalone message in the TUI/browser.
If it still acts weird, clean up the broken session entry.

Preview first:

openclaw sessions cleanup --store "/home/michael/.openclaw/agents/main/sessions/sessions.json" --dry-run --fix-missing

#

Then actually fix it:

openclaw sessions cleanup --store "/home/michael/.openclaw/agents/main/sessions/sessions.json" --enforce --fix-missing
openclaw gateway restart

Then Hatch again.

What this does: it removes stale session records whose transcript files are already gone.

If it still hangs after that, then I’d go back to the local-model angle and enable lean mode:

openclaw config set agents.defaults.experimental.localModelLean true
openclaw gateway restart

#

So the order I’d use now is:

fresh session /new → sessions cleanup → retry → lean mode if needed

#

The rest of that Doctor output looks normal enough. The actionable part is still the missing main session transcript.

So I wouldn’t keep scrolling Doctor now. I’d do this next:

In the TUI/browser, send /new as a standalone message.
If it still hangs, run:

openclaw sessions cleanup --store "/home/michael/.openclaw/agents/main/sessions/sessions.json" --enforce --fix-missing
openclaw gateway restart

Then Hatch again.

So, short version: we found a stale/broken session entry, and that’s the first thing I’d fix before chasing anything else.

#

Yep, that part is unrelated too. We’ve got enough now, I don’t need any more Doctor output.

Next step: try /new in the TUI/browser as a standalone message.

If that still hangs, then run:

openclaw sessions cleanup --store "/home/michael/.openclaw/agents/main/sessions/sessions.json" --enforce --fix-missing
openclaw gateway restart

The shell completion prompt and the rest of Doctor are just noise for this issue. The real lead is still the missing main session transcript.

#

You can ignore Memory search for this. It is not required for basic chat/hatching.

So, really, stop Doctor here and do this:

Send /new in the TUI/browser.
If it still hangs, run:

openclaw sessions cleanup --store "/home/michael/.openclaw/agents/main/sessions/sessions.json" --enforce --fix-missing
openclaw gateway restart

Then try Hatch again.

We already found the only part of Doctor that looks relevant: the missing main session transcript.

#

Those memory API key warnings are unrelated too. Do not go configure memory providers for this. It won’t fix the hatch hang.

At this point, please do one of these and tell me what happened:

Option 1, safest first

send /new in the TUI/browser

Option 2, if /new still hangs

openclaw sessions cleanup --store "/home/michael/.openclaw/agents/main/sessions/sessions.json" --enforce --fix-missing
openclaw gateway restart

Then retry Hatch.

So the only thing I need back now is: did /new work, or did you run the cleanup, and what happened after?

#

Nice, we finally found the real issue.

This proves it is not the TUI, browser UI, or basic gateway setup. The model itself is timing out in OpenClaw:

ollama/gemma4 produced no reply before the idle watchdog
default idle timeout is kicking in before Gemma returns anything

So the next thing I’d try is:

openclaw config set agents.defaults.llm.idleTimeoutSeconds 600
openclaw config set agents.defaults.experimental.localModelLean true
openclaw gateway restart

Then test again with:

#

openclaw infer model run --model ollama/gemma4 --prompt "Say hi in one short sentence." --json

Why this helps:

idleTimeoutSeconds 600 gives the model up to 10 minutes before OpenClaw gives up
localModelLean true reduces prompt/tool overhead, which helps slower local models

My guess is that on a CPU-only mini PC, Gemma is just too slow to produce the first token within the default 120s once OpenClaw adds its heavier prompt.

If it still times out after that, I’d stop fighting Gemma for first setup and try a faster/smaller local model or a temporary cloud model just to confirm the rest of the install is solid.

Docs:
https://docs.openclaw.ai/gateway/local-models
https://docs.openclaw.ai/concepts/experimental-features

manic flare Apr 19, 2026, 6:01 PM

#

This was working, and i was able to start using my agent, however, responses were slow. My assistant then started hanging on responses and not outputting anything again. I have tried changing the model to an older version, but I am still not getting a reply from my agent.

void solarBOT Apr 19, 2026, 6:02 PM

#

That pattern makes sense for a slow local model. It works at first, gets slower as the session grows, then eventually stops replying because the run is taking too long or the context got too heavy.

I’d try this order:

Start fresh
- send /new as a standalone message
- if you want to keep the current session instead, try /compact
Make sure the slow-local-model settings are still applied

openclaw config set agents.defaults.llm.idleTimeoutSeconds 600
openclaw config set agents.defaults.experimental.localModelLean true
openclaw gateway restart

Retry with the direct test

#

openclaw infer model run --model ollama/gemma4 --prompt "Say hi in one short sentence." --json

Why I’d do /new first: changing to an older model does not help much if the current session is already bloated. A fresh session removes that variable immediately.

If it keeps happening even after /new + the timeout/lean settings, I’d be pretty suspicious that the model is just too slow for comfortable agent use on that box, and I’d switch to a faster local model or a temporary cloud model.

Docs:
https://docs.openclaw.ai/concepts/compaction
https://docs.openclaw.ai/gateway/local-models

If you want, paste what happens after /new or that infer model run test and I’ll help narrow it down.

manic flare Apr 19, 2026, 6:12 PM

#

When calling for /new I get: openclaw tui - ws://127.0.0.1:18789 - agent main - session main
openclaw tui - ws://127.0.0.1:18789 - agent main - session
tui-1d754671-a2ff-4bb4-a607-d3ea35a39d65

Pairing required. Run openclaw devices list, approve your request ID, then
reconnect.

history failed: Error: gateway not connected

sessions list failed: Error: gateway not connected

new session: tui-1d754671-a2ff-4bb4-a607-d3ea35a39d65
disconnected | idle
agent main | session tui-1d754671-a2ff-4bb4-a607-d3ea35a39d65 | unknown |
tokens ?

void solarBOT Apr 19, 2026, 6:13 PM

#

Yep, this is a pairing/scope problem now, separate from the slow-model issue.

The key line is:

Pairing required
history failed: gateway not connected

That means the TUI asked the gateway for a new session, but the device/token was not approved for that action, often a scope upgrade like operator.write.

Try this on the machine running the gateway:

openclaw devices list

You should see a pending request. Then approve it with the exact request ID:

#

openclaw devices approve <requestId>

Then reconnect the TUI and try /new again.

If devices list shows nothing pending, reopen the TUI first, then quickly run openclaw devices list again so the fresh request is visible.

So at this point I’d do:

approve the pending device request
reconnect TUI
retry /new
if replies are still slow/hanging after that, keep using the idleTimeoutSeconds 600 + localModelLean true settings

Docs:
https://docs.openclaw.ai/cli/devices

#

https://docs.openclaw.ai/gateway/troubleshooting

manic flare Apr 20, 2026, 12:21 AM

#

I tried to change the model to qwen3.5:9b When I ran the dashboard, I had the agent run a health check. With the new model, it wanted to fix some issues, I granted permission and it replied:

Perfect! Configuration updated successfully:
✅ sandbox.mode: "all" added to agents.defaults
✅ allowInsecureAuth: false set for gateway.controlUi
✅ tools.deny: ["group:web", "browser"] added

Now I need to restart the gateway for changes to take effect.

After restarting, nothing happened, so when I prompted the aget I got this error:

Agent failed before reply: Sandbox mode requires Docker, but the "docker" command was not found in PATH. Install Docker (and ensure "docker" is available), or set agents.defaults.sandbox.mode=off to disable sandboxing. | spawn docker ENOENT.
Logs: openclaw logs --follow

I then installed Docker. Prompting the agent this time gave the error:

Agent failed before reply: Failed to inspect sandbox image: permission denied while trying to connect to the docker API at unix:///var/run/docker.sock.
Logs: openclaw logs --follow

I then set the agents.defaults.sandbox.mode to off.

I then sent a prompt to the agent, and it is stuck in the thinking stage, no timeouts or errors.

Thinking that I may have an issue with ollama, I went to get the desktop app for LM Studio. But when I try to run the AppImage I get the error:

./LM-Studio-0.4.12-1-x64.AppImage
[35540:0419/200630.502384:FATAL:sandbox/linux/suid/client/setuid_sandbox_host.cc:166] The SUID sandbox helper binary was found, but is not configured correctly. Rather than run without sandboxing I'm aborting now. You need to make sure that /tmp/.mount_LM-StupXnEHk/chrome-sandbox is owned by root and has mode 4755.
Trace/breakpoint trap (core dumped)

Can I fix this?

void solarBOT Apr 20, 2026, 12:22 AM

#

Yeah, you’ve got two separate problems tangled together now:

Sandbox/Docker
Local model speed/stability

For getting unstuck, I’d simplify hard:

1) Leave sandboxing off for now

The health check made reasonable hardening changes, but it also made your setup more complex.

docker.sock permission denied means Docker is installed but your user still cannot talk to the Docker daemon. That is a Docker permissions issue, not the root cause of slow/hanging model replies.

So for now, keep:

openclaw config set agents.defaults.sandbox.mode off

#

2) Keep the slow-local-model mitigations

openclaw config set agents.defaults.llm.idleTimeoutSeconds 600
openclaw config set agents.defaults.experimental.localModelLean true
openclaw gateway restart

3) Test the model outside the UI first

Before touching Dashboard/TUI again, run:

openclaw infer model run --prompt "Reply with exactly: smoke-ok" --json

If that hangs, the problem is still model/runtime. If that works, then do /new and retry the UI.

4) About LM Studio

#

That AppImage error is LM Studio’s own Linux/Chromium sandbox issue, not an OpenClaw bug.

You probably can fix it, but honestly I would not fight the AppImage first. On Ubuntu, the easier path is usually LM Studio’s headless daemon/server route instead of the desktop AppImage.

OpenClaw’s LM Studio docs support that path:
https://docs.openclaw.ai/providers/lmstudio

So my recommendation is:

keep sandbox off
keep idleTimeoutSeconds=600
keep localModelLean=true
test with openclaw infer model run
only after that, decide whether to stay on Ollama or switch to LM Studio

If you paste the output of that infer model run now, I can tell you pretty quickly which side is still broken.

manic flare Apr 20, 2026, 12:40 AM

#

michael@AInchor:~/Desktop$ openclaw infer model run --prompt "Reply with exactly: smoke-ok" --json
20:27:44 [agent/embedded] Merged and removed orphaned user message to prevent consecutive user turns. runId=90328d52-a57f-47fe-895c-74c0e7f0e71a sessionId=90328d52-a57f-47fe-895c-74c0e7f0e71a trigger=user
20:32:45 [agent/embedded] embedded run agent end: runId=90328d52-a57f-47fe-895c-74c0e7f0e71a isError=true model=qwen3.5:9b provider=ollama error=LLM request failed: network connection error. rawError=fetch failed | Headers Timeout Error
20:37:48 [agent/embedded] embedded run agent end: runId=90328d52-a57f-47fe-895c-74c0e7f0e71a isError=true model=qwen3.5:9b provider=ollama error=LLM request failed: network connection error. rawError=fetch failed | Headers Timeout Error

void solarBOT Apr 20, 2026, 12:41 AM

#

This is actually really helpful.

Headers Timeout Error means OpenClaw did reach Ollama, but Ollama never started sending response headers in time. So right now the blocker looks upstream of OpenClaw, in the Ollama/model runtime path.

I’d stop changing sandbox/LM Studio for a minute and test Ollama directly:

ollama ps
ollama run qwen3.5:9b "Reply with exactly: smoke-ok"

What I’m looking for:

if ollama run ... is also slow/hangs, then this is an Ollama/model/hardware problem
if ollama run ... is fast, but openclaw infer model run ... still times out, then we look back at the OpenClaw side

That infer model run test already bypasses the UI, so this is no longer a Dashboard/TUI problem.

#

So for now, I’d keep it simple:

sandbox off
no more health-check auto-fixes
no LM Studio detour yet
test Ollama directly

Paste the output of those two Ollama commands and we can narrow it down fast.

manic flare Apr 20, 2026, 12:45 AM

#

michael@AInchor:~$ ollama ps
NAME ID SIZE PROCESSOR CONTEXT UNTIL
qwen3.5:9b 6488c96fa5fa 18 GB 100% CPU 262144 4 minutes from now
michael@AInchor:~$ ollama run qwen3.5:9b "Reply with exactly: smoke-ok"
Thinking...
Thinking Process:

Analyze the Request: The user is asking me to reply with exactly the string
"smoke-ok".
Check Constraints: The instruction is explicit: "Reply with exactly: smoke-ok".
I need to ensure no extra text, explanations, or formatting is added.
Verify Safety: The phrase "smoke-ok" does not inherently violate safety
policies. It's a simple string. However, the word "smoke" could potentially relate to
smoking, but the instruction is just to output the string. I should not interpret this
as a request to encourage smoking or provide information about it, just follow the
instruction to output the text.
Formulate Output: The only correct output is the characters s-m-o-k-e---o-k.
Final Review: Does this comply with "exactly"? Yes.
Execute: Output "smoke-ok".ot
...done thinking.

smoke-ok

void solarBOT Apr 20, 2026, 12:48 AM

#

That actually narrows it down a lot.

Your install is basically working. The problem is that this model is very slow for agent use on CPU:

ollama run works
but it shows a long Thinking... phase even for smoke-ok
ollama ps shows 100% CPU and a 262144 context
OpenClaw sends a much heavier prompt than plain ollama run, so it is likely missing the HTTP headers timeout before the model starts responding

So I would not call this a broken OpenClaw install anymore. It looks like a model/hardware/latency mismatch.

Best next options

Option 1, recommended

Use a faster/smaller non-thinking local model as your OpenClaw primary model.

This is the easiest way to get a usable agent experience.

#

Option 2, more advanced

Keep qwen3.5:9b, but lower the configured context window in OpenClaw from the discovered 262144 to something much smaller like 32768 or 65536.

That can help a lot on CPU-only machines, but it means editing the Ollama model config explicitly.

Option 3

Use a temporary cloud model just to confirm the rest of your setup is solid, then come back and tune local models later.

What I’d keep right now

sandbox: off
localModelLean: true
use /new when sessions get slow

If you want, I can help with either:

the simple path: pick a faster local model and wire it cleanly, or

#

the tuning path: write the exact JSON5 to cap Ollama’s context window for qwen3.5:9b

Docs:
https://docs.openclaw.ai/providers/ollama
https://docs.openclaw.ai/gateway/local-models

manic flare Apr 20, 2026, 12:53 AM

#

Can you help me with picking a faster local model? I do not need one with image recognition. I currently also have pulled models for mistral:7b and llama3.2:3b

void solarBOT Apr 20, 2026, 12:55 AM

#

Between those two, I’d try mistral:7b first.

My quick take:

llama3.2:3b: faster, but more likely to feel weak/fragile for agent use
mistral:7b: still lighter than what you were trying, but has a better chance of being actually usable

So my recommendation would be:

openclaw models set ollama/mistral:7b
openclaw gateway restart

Then test it with:

#

openclaw infer model run --prompt "Reply with exactly: smoke-ok" --json

If mistral:7b is still too slow, then drop to llama3.2:3b for raw speed.

I’d also keep these on for local models:

openclaw config set agents.defaults.llm.idleTimeoutSeconds 600
openclaw config set agents.defaults.experimental.localModelLean true

One more honest note: for real agent use, CPU-only local models are still a rough tradeoff between speed and capability. If you want current hands-on model recommendations beyond these two, ask in #models too, since that changes fast:
https://docs.openclaw.ai/concepts/models
https://docs.openclaw.ai/concepts/models#model-discussions-community-notes

#

And if mistral:7b works, please mark the solution 🎉
Right-click the solution message → Apps → ✅ Mark Solution

tranquil marsh Apr 20, 2026, 1:06 AM

#

so i'm running 20 agents, and curious which model would be the best for Saas

void solarBOT Apr 20, 2026, 1:07 AM

#

For 20 agents / SaaS, there isn’t one fixed “best” model. The tradeoff is usually:

tool reliability
latency
cost
context size

For current hands-on recommendations, ask in #models. That changes too fast for me to give a reliable hard pick here.

Docs:
https://docs.openclaw.ai/concepts/models
https://docs.openclaw.ai/concepts/models#model-discussions-community-notes

Short rule of thumb from the docs: for tool-heavy, user-facing agents, use the strongest reliable model you can afford, then add cheaper fallbacks for lower-stakes work. Since this thread is about a different issue, I’d open a fresh thread or continue in #models for SaaS model advice.

manic flare Apr 20, 2026, 1:22 AM

#

I tried both the mistral and llama models, and both timed out. Can I test this with a free tier of a cloud based model, or will I need a paid subscription?

void solarBOT Apr 20, 2026, 1:23 AM

#

Yes, you can test with a hosted model, and no, it does not have to be an API-key-only paid setup.

Short version:

Free tiers can work for a smoke test, but they’re often rate-limited/inconsistent, so they’re not my favorite for debugging agent issues.
If you already have a supported subscription/OAuth route, that’s a good quick test.
The most predictable path is still a paid API key.

So if your goal is just “prove OpenClaw works on my machine”, I’d use whichever of these you already have:

Anthropic API key or Claude CLI/subscription auth
OpenAI Codex OAuth
another supported hosted provider you already pay for

Then switch via:

#

openclaw configure --section model

or rerun:

openclaw onboard

I’d mainly avoid relying on a random free tier for this specific debugging step, because if it flakes out you won’t know whether the problem is your setup or the provider limits.

Docs:
https://docs.openclaw.ai/help/faq#do-i-need-a-claude-or-openai-subscription-to-run-this
https://docs.openclaw.ai/concepts/models
https://docs.openclaw.ai/start/wizard

#

If you tell me what subscriptions or API keys you already have, I can point you to the least painful option to test with.

manic flare Apr 20, 2026, 1:26 AM

#

I don't currently pay for any models. I wasn't sure which one to go with. I understand anthropic is limiting openclaw for some users? I was thinking of using gemini, but I'm not sure which one is best for me.

void solarBOT Apr 20, 2026, 1:27 AM

#

If you’re starting from zero paid providers, I’d keep it simple:

Don’t chase free tiers for this, they’re too flaky for debugging
use a normal paid API key first, just to prove your OpenClaw setup works
once hosted works, come back to local models

On the Anthropic part, the docs say Claude CLI/subscription auth is supported again, but API keys are still the more predictable setup for real use. So it’s less “Anthropic is blocking OpenClaw” and more “subscription-style quotas can be less predictable than straight API billing.”

If you’re leaning Gemini, that’s a perfectly reasonable first hosted provider to try. I just would not frame it as “the best,” because that changes fast and depends on cost, latency, and how tool-heavy your workflow is.

My practical recommendation:

pick one hosted provider
use the simplest paid API key path
get OpenClaw working end-to-end
then compare providers later

#

For live model/provider opinions, ask in #models. That’s the right place for current hands-on recommendations.

Docs:
https://docs.openclaw.ai/help/faq#do-i-need-a-claude-or-openai-subscription-to-run-this
https://docs.openclaw.ai/concepts/models
https://docs.openclaw.ai/concepts/models#model-discussions-community-notes

If you want the least-painful path, I’d say: hosted API key first, local tuning second.

manic flare Apr 20, 2026, 1:28 AM

#

Can you suggest a model that is currently good at tool use?

void solarBOT Apr 20, 2026, 1:29 AM

#

I don’t want to give you a stale hard pick here.

For tool use, the general rule is:

favor hosted models
prioritize tool-calling reliability over raw benchmark hype
avoid small local models if the agent needs to do real work

For the current best hands-on recommendations, ask in #models. That changes fast, and I’m specifically supposed to point people there instead of pretending my list is fresh.

Docs:
https://docs.openclaw.ai/concepts/models
https://docs.openclaw.ai/concepts/models#model-discussions-community-notes

If you want, I can still help you narrow the type of model/provider to look for, for example cheapest decent tool-user vs easiest hosted setup vs best reliability.

manic flare Apr 20, 2026, 1:33 AM

#

I'm sorry, I can't locate #models, should I ask in #1478196963563409520 ?

void solarBOT Apr 20, 2026, 1:33 AM

#

No worries, I meant #models.

If you still can’t find it, asking in #users-helping-users for real human recommendations is also totally fine. You can say you’re looking for a hosted model that’s currently good at tool use in OpenClaw.

And if you want to keep going here, I can still help with the setup side once you pick a provider.

manic flare Apr 20, 2026, 12:10 PM

#

I now have a subscription for ChatGPT, how should I set it up?

void solarBOT Apr 20, 2026, 12:11 PM

#

Yep, with a ChatGPT subscription, the path you want is OpenAI Codex OAuth, not an OpenAI API key.

The important distinction from the docs:

openai-codex/* = ChatGPT/Codex sign-in
openai/* = direct OpenAI API billing

So if you already finished onboarding, the simplest setup is:

openclaw models auth login --provider openai-codex --set-default

That should run the browser auth flow and set your default model route appropriately.

If you want the guided path instead, you can rerun:

#

openclaw onboard --auth-choice openai-codex

Then verify with:

openclaw models status
openclaw models list --provider openai-codex

So, short version: use openai-codex, not openai, unless you separately buy OpenAI API credits.

Docs:
https://docs.openclaw.ai/help/faq#how-does-codex-auth-work
https://docs.openclaw.ai/help/faq#why-does-chatgpt-gpt-54-not-unlock-openaigpt-54-in-openclaw
https://docs.openclaw.ai/providers/openai

#

If you want, after you run that, paste the openclaw models status output and I’ll sanity-check it.

manic flare Apr 20, 2026, 12:19 PM

#

And once I get the model changed, I can load up the agent in the dashboard?

void solarBOT Apr 20, 2026, 12:20 PM

#

Yes, that’s the idea.

Once the hosted model auth is set up correctly, you should be able to use the agent in the Dashboard. I’d just do one quick sanity check first before trusting the UI:

openclaw infer model run --prompt "Reply with exactly: smoke-ok" --json

If that works, then:

open the Dashboard
start a fresh session if needed with /new
try the agent there

Given all the local-model weirdness you hit earlier, I’d definitely test the model path once in CLI first, then move to the Dashboard.

manic flare Apr 20, 2026, 12:23 PM

#

This time I got: michael@AInchor:~$ openclaw infer model run --prompt "Reply with exactly: smoke-ok" --json
{
"ok": true,
"capability": "model.run",
"transport": "local",
"provider": "openai-codex",
"model": "gpt-5.4",
"attempts": [],
"outputs": [
{
"text": "smoke-ok",
"mediaUrl": null
}
]
}

void solarBOT Apr 20, 2026, 12:23 PM

#

Perfect, that’s the proof we wanted 🎉

Your hosted model path is working now:

provider: openai-codex
model: gpt-5.4
direct infer succeeded

So yes, at this point you should be able to use the agent in the Dashboard.

I’d do this next:

open the Dashboard
start a fresh session with /new if the old one still looks weird
send a normal prompt

If the Dashboard still misbehaves now, it’s probably no longer a model/auth problem, it would be session/UI state.

#

Glad we finally got you to a real smoke-ok 😄

If this got you unstuck, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it.

manic flare Apr 20, 2026, 12:25 PM

#

But, the command did not reply with only outputting "smoke-ok" It returned all the code shown in brackets

void solarBOT Apr 20, 2026, 12:25 PM

#

Yep, that’s expected because you ran it with --json.

--json wraps the reply in a JSON object, so the important part is this bit:

"outputs": [
  {
    "text": "smoke-ok"
  }
]

So the model did reply correctly.

If you want plain text only, run it without --json:

#

openclaw infer model run --prompt "Reply with exactly: smoke-ok"

So you’re good, the hosted model path is working.

manic flare Apr 20, 2026, 12:26 PM

#

Thank you for clarifying that!

#Everything new - not working

1) Leave sandboxing off for now

2) Keep the slow-local-model mitigations

3) Test the model outside the UI first

4) About LM Studio

Best next options

Option 1, recommended

Option 2, more advanced

Option 3

What I’d keep right now