Goal Run OpenClaw locally on Windows using WSL2, with Ollama serving qwen3:4b | Friends of the Crustacean 🦞🤝 | Page 1

sinful juniper Apr 28, 2026, 9:40 AM

#

OpenClaw TUI and browser dashboard both hang on every message with stuck session: state=processing. The model never replies — instead it loops infinitely on a BOOTSTRAP.md system prompt, outputting internal reasoning instead of answers.
Direct ollama run works perfectly. The model is fine. The problem is specifically OpenClaw's agent session handling on WSL2.
Key log line:
stuck session: sessionId=unknown sessionKey=agent:main:main state=processing age=192s queueDepth=1
Environment: WSL2, Ubuntu, Ollama, qwen3:4b 100% GPU, OpenClaw v2026.4.26.

past mistBOT Apr 28, 2026, 9:41 AM

#

Moosse, I’d treat this as bootstrap/session got wedged + qwen3:4b failing the full agent prompt, not proof that Ollama itself is broken.

Try this order:

Abort/reset the active session:

/stop
/new

In WSL, check for a stuck bootstrap sentinel:

ls -la ~/.openclaw/workspace/BOOTSTRAP.md

If it exists and bootstrap keeps repeating, move it aside, then restart:

#

mv ~/.openclaw/workspace/BOOTSTRAP.md ~/.openclaw/workspace/BOOTSTRAP.md.stuck-$(date +%Y%m%d-%H%M%S)
openclaw gateway restart

BOOTSTRAP.md is supposed to be removed after first-run bootstrap completes. (docs.openclaw.ai)

Make sure Ollama is configured with the native Ollama API, not /v1:

baseUrl: "http://127.0.0.1:11434"
api: "ollama"

The /v1 OpenAI-compatible Ollama path can break tool calling / produce raw tool text. (docs.openclaw.ai)

Then test the Gateway route:

#

openclaw infer model run --gateway --model ollama/qwen3:4b --prompt "Reply with exactly: pong" --json

If that works but normal chat still hangs, enable the local lean mode first:

agents: {
  defaults: {
    experimental: {
      localModelLean: true
    }
  }
}

For small/strict local models, docs recommend localModelLean first, then disabling tool schemas with compat.supportsTools: false if needed. (docs.openclaw.ai)

OpenClaw

Local models - OpenClaw

sinful juniper Apr 28, 2026, 10:48 AM

#

did everything - this (exerpt below) is still happening in the tui:

hi
But in this case, the user hasn't actually made a query—they've just provided the context. Wait, no, the problem is structured as a simulation where
the user is providing the context and expects me to generate the appropriate function call.

nder's metadata. The assistant's job is to figure out which function to call next. However, since there's no
actual user query here (the user provided the context), maybe the correct response is to use a function like sessions_status to check the current
session status.

Wait, the problem states: "OpenClaw runtime context for the immediately preceding user message." So this is the context that the assistant has to
work with. The user is probably expecting the assistant to generate the next function call based on this context.

Given that the context includes the sender as "openclaw-tui", which is a TUI (text user interface) session, maybe the assistant should check the
session status to get more details.

Looking at the tools, sessions_status is a function that shows the session status card. Since the user provided the sender metadata, perhaps the next step is to get the session status.

So the function to call would be sessions_status with sessionKey="current".
Let me check the sessions_status function definition: it takes optional model and sessionKey. The user's context mentions the current session (since
it's the immediately preceding user message), so sessionKey="current".

Therefore, the correct function call is sessions_status with arguments {"sessionKey": "current"}.

Wait, but the problem says "For each function call, return a json object with function name and arguments within XML tag

past mistBOT Apr 28, 2026, 10:49 AM

#

That excerpt is the smoking gun: qwen3:4b is not following OpenClaw’s agent/tool protocol. It’s treating runtime metadata/tool instructions as the user task and dumping its chain-of-thought-ish planning into the reply.

So the stuck session is likely a symptom, but the root now is model/tool incompatibility, not WSL2 or Ollama being dead.

Try the “no tools / lean agent” setup:

{
  agents: {
    defaults: {
      experimental: {
        localModelLean: true
      }
    }
  },
  models: {

#

    providers: {
      ollama: {
        baseUrl: "http://127.0.0.1:11434",
        apiKey: "ollama-local",
        api: "ollama",
        models: [
          {
            id: "qwen3:4b",
            name: "qwen3:4b",
            reasoning: false,
            input: ["text"],
            compat: {
              supportsTools: false
            }
          }

#

Then:

openclaw gateway restart
/new

If it still prints stuff like “which function to call next”, then I’d stop fighting this model as the main OpenClaw agent. qwen3:4b can pass direct Ollama chat and still fail OpenClaw because OpenClaw’s normal agent prompt includes session metadata, bootstrap context, tool schemas, and safety scaffolding. A 4B local reasoning model is very likely to leak/roleplay that instead of producing final answers.

#

Practical next move: use a bigger/local model for the main agent, or use hosted/cloud for main and keep qwen3:4b only for narrow infer model run style tasks. Also please file this as a GitHub issue with that excerpt + openclaw status --all: https://github.com/openclaw/openclaw/issues

sinful juniper Apr 28, 2026, 10:55 AM

#

Qwen3:4b is conflating the system prompt with user input. It's treating OpenClaw's injected control instructions (BOOTSTRAP.md, HEARTBEAT.md, tool schemas, runtime context) as if they were user questions to reason about, rather than system-level directives to silently execute and move on from.
A capable model like GPT-4 or Claude would:

Read BOOTSTRAP.md silently
Execute it
Reply to the user normally

Qwen3:4b instead:

Reads the system prompt
Reasons out loud about what the system prompt means
Debates with itself whether to call tools
Eventually produces an answer to the system prompt rather than the user's question
Repeats this entire process on the next message because it never truly "completed" bootstrap

This is a model capability issue — qwen3:4b at 4 billion parameters doesn't have reliable enough instruction-following to separate system context from user conversation. It's essentially not agent-capable at this size.
what are my options?

past mistBOT Apr 28, 2026, 10:55 AM

#

Yeah, that diagnosis is basically right. I would not keep trying to make qwen3:4b the main OpenClaw agent.

Your real options, in order of likely success:

Use a stronger model for the main agent
- Best “it just works” path: hosted/cloud model as primary.
- Keep Ollama/local as fallback or for narrow tasks.
- This is the recommended route if you want TUI/dashboard/chat to behave like an actual agent.
Stay local, but use a much more capable local model
- Use Ollama native API, not /v1:
```
baseUrl: "http://127.0.0.1:11434"
api: "ollama"
```
- Use the largest model your GPU/VRAM can realistically run.
- Ask in #models for current local recommendations — model quality changes too fast for me to confidently list picks here.

#

Use qwen3:4b only as a “dumb text model,” not an agent
Configure it with:

agents: {
  defaults: {
    experimental: {
      localModelLean: true
    }
  }
},
models: {
  providers: {
    ollama: {
      baseUrl: "http://127.0.0.1:11434",
      apiKey: "ollama-local",
      api: "ollama",

#

         models: [
           {
             id: "qwen3:4b",
             name: "qwen3:4b",
             reasoning: false,
             input: ["text"],
             compat: {
               supportsTools: false
             }
           }
         ]
       }
     }
   }

This removes a lot of the agent/tool surface. If it works, expect a very limited assistant: fewer tools, worse autonomy, less reliability.

#

Use it only through infer model run / narrow jobs
Example:
```
openclaw infer model run --gateway --model ollama/qwen3:4b --prompt "Reply with exactly: pong" --json
```
If this works but normal chat fails, that confirms the model can answer simple prompts but cannot handle OpenClaw’s full agent runtime.
If a stronger model still gets state=processing, file a bug
At that point it’s no longer “4B model can’t follow instructions”; it may be session handling. Include:
```
openclaw status --all
openclaw logs --follow
```
and the stuck line. Issue tracker: https://github.com/openclaw/openclaw/issues

Docs worth keeping open:

https://docs.openclaw.ai/providers/ollama

#

Blunt recommendation: use a stronger primary model first, get OpenClaw working end-to-end, then experiment with small local models after you know the rest of the stack is healthy.

sinful juniper Apr 28, 2026, 1:30 PM

#

ok followed your advice, now with gemini - getting this after Verrrry slow response times. like 1980's dialup speed

#

Agent failed before reply: No API key found for provider "google". Auth store: /home/bmubuntu/.openclaw/agents/main/agent/auth-profiles.json (agentDir: /home/bmubuntu/.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/bmubuntu/.openclaw/agents/main/agent/auth-profiles.json (agentDir: /home/bmubuntu/.openclaw/agents/main/agent). Configure auth for this agent (openclaw agents add <id>) or copy auth-profiles.json from the main agentDir.
Logs: openclaw logs --follow

past mistBOT Apr 28, 2026, 1:30 PM

#

That sounds like progress: Gemini is at least responding now, but we need to separate provider slowness from OpenClaw session/context slowness.

First: I don’t see the “getting this” excerpt/attachment in Discord here — can you paste the exact error/output?

Meanwhile, try these quick checks:

openclaw --version
openclaw status --all
openclaw models status

Then test Gemini without the full agent/session context:

openclaw infer model run --gateway --model <your-google-model-ref> --prompt "Reply with exactly: pong" --json

#

How to read it:

infer model run is fast, but TUI is slow → session/context/tool/bootstrap overhead. Start clean:
```
/new
/think off
```
Then restart:
```
openclaw gateway restart
```
infer model run is also slow → Gemini/auth/provider path is slow. If you’re using Gemini CLI OAuth, try a Gemini API key instead; spawning/using CLI-style auth can be noticeably slower than direct API access.
Only “thinking” responses are slow → lower/disable thinking:

#

  /think off

or use a faster Gemini variant. For current best model picks, ask in #models — that changes too fast for me to hardcode confidently.

Docs:
https://docs.openclaw.ai/providers/google
https://docs.openclaw.ai/gateway/troubleshooting

#

That one is straightforward: Gemini isn’t slow here — the agent has no Google credential.

Fix with either API-key auth or Gemini CLI OAuth:

Option A: Gemini API key — simplest

export GEMINI_API_KEY="your-key"
openclaw onboard --auth-choice gemini-api-key
openclaw gateway restart
openclaw models status

If the gateway is running as a daemon/systemd service, the shell export may not be visible to it. Put it in:

~/.openclaw/.env

#

like:

GEMINI_API_KEY=your-key

then:

openclaw gateway restart

Option B: Gemini CLI OAuth
If you used Gemini CLI login instead of an API key, make sure OpenClaw is configured for the Gemini CLI runtime, not plain google API-key auth. Docs: https://docs.openclaw.ai/providers/google

After auth is fixed, verify:

#Goal Run OpenClaw locally on Windows using WSL2, with Ollama serving qwen3:4b