Happy to Pay for services | Friends of the Crustacean 🦞🤝 | Page 1

versed elbow Feb 16, 2026, 3:52 PM

#

I need help here. I have a 5090Ti 16gb vram set up. I'm trying to run locally with qwen3:14b and I'm on Linux. None stop issues
If there are any experts that can assist me or point me in the right direction, it would be greatly appreciated and I would compensate for time.
DM me

rough spadeBOT Feb 16, 2026, 3:52 PM

#

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

median islandBOT Feb 16, 2026, 3:53 PM

#

If you can, keep it in this thread / in #help (instead of DMs) so others can learn + we can see logs safely. I also can’t do DMs.

To get you unstuck, I need 4 concrete bits (copy/paste is fine, redact keys):

What are the “non stop issues” exactly?
- OOM / VRAM errors?
- model keeps looping / never finishes?
- OpenClaw tool calls failing (“Tool … not found”, JSON schema errors), etc.
How are you running qwen3:14b locally? (Ollama / vLLM / llama.cpp / LM Studio / something else) + the exact command/config.
Your versions:

openclaw --version
nvidia-smi
ollama --version   # if using ollama

#

The relevant logs (last ~50-100 lines) from whatever is orchestrating it (OpenClaw gateway logs, ollama server logs, etc.).

One very common gotcha with OpenClaw specifically: local / non-Anthropic models often struggle with strict tool-calling + JSON schemas, which can look like “it never stops”, ignores tool results, or hallucinates tool names. A practical workaround is:

use a tool-reliable cloud model for the agent/orchestrator, and
keep the local model for “chat/completion-only” tasks (no tools).

If you paste the exact symptom + how you wired qwen into OpenClaw, I can tell you whether you’re hitting VRAM/quantization limits vs tool-calling reliability vs a config issue—and what the shortest fix path is. Also worth asking in #models for up-to-date “qwen local” success configs: https://docs.openclaw.ai/concepts/models#model-discussions-community-notes

versed elbow Feb 16, 2026, 4:24 PM

#

median island If you can, keep it in this thread / in **#help** (instead of DMs) so others can...

I will keep this in the thread and post any solutions found here. I'll get you this information when I get back to my machine later in the day. Thank you for reaching out

median islandBOT Feb 16, 2026, 4:24 PM

#

Sounds good.

When you’re back at the machine, the fastest way to make this actionable is to paste these (in order):

Exact symptom (copy the error text, or describe the looping behavior)
Output of:

openclaw --version
nvidia-smi

and (depending on what you’re using)

ollama --version
ollama show qwen3:14b

(or your vLLM/llama.cpp equivalent)

#

How OpenClaw is pointed at the local model (the relevant snippet from your config + what provider/baseUrl you used — redact tokens)
Logs: last ~100 lines from the failing component (OpenClaw gateway log + local model server log)

Once I see those, I can usually tell within one round-trip whether it’s:

VRAM/quantization/context-window pressure,
CUDA / driver mismatch,
or the classic “model can’t reliably do tool-calling / JSON schemas” problem (which has a couple straightforward workarounds).

versed elbow Feb 16, 2026, 11:31 PM

#

+-----------------------------------------------------------------------------------------+
| Processes: |
| GPU GI CI PID Type Process name GPU Memory |
| ID ID Usage |
|=========================================================================================|
| 0 N/A N/A 2379 G /usr/lib/xorg/Xorg 248MiB |
| 0 N/A N/A 2625 G /usr/bin/gnome-shell 98MiB |
| 0 N/A N/A 3427 G .../7766/usr/lib/firefox/firefox 314MiB |
+-----------------------------------------------------------------------------------------+

#

$ ollama --version
ollama show qwen3:14b
ollama version is 0.16.1
Model
architecture qwen3
parameters 14.8B
context length 40960
embedding length 5120
quantization Q4_K_M

Capabilities
completion
tools
thinking

Parameters
top_k 20
top_p 0.95
repeat_penalty 1
stop "<|im_start|>"
stop "<|im_end|>"
temperature 0.6

License
Apache License
Version 2.0, January 2004
...

median islandBOT Feb 16, 2026, 11:33 PM

#

Good info — you’re on OpenClaw 2026.2.14, and the machine is seeing a 5070 Ti 16GB (note: that doesn’t match the “5090Ti” you mentioned earlier, so double-check you’re on the right box).

Next step: I need the actual failure mode + whether the local model works outside OpenClaw.

1) Is Ollama/vLLM/llama.cpp itself stable?

If you’re using Ollama, paste outputs of:

ollama --version
ollama ps
ollama show qwen3:14b

Then run a dead-simple prompt and tell me what happens (does it finish? loop? error?):

ollama run qwen3:14b "Reply with exactly: OK"

#

While that’s running, in another terminal watch VRAM climb:

nvidia-smi -l 1

If VRAM doesn’t jump up, the model server likely isn’t using the GPU (or is falling back).
If it jumps to ~15-16GB then errors, you’re likely hitting a VRAM/context/quantization limit.

2) If the model works fine alone, it’s probably OpenClaw/tooling

Paste:

openclaw status
openclaw models status
openclaw logs --follow

Then reproduce the “non stop” issue once and copy the first real error you see in the logs (stack traces are fine).

Also: when you say “non stop issues”, do you mean:

#

it keeps generating forever / repeating,
it keeps trying tools repeatedly,
or the whole agent run never finishes?

3) How is OpenClaw pointed at qwen3?

Paste the relevant snippet from your OpenClaw config (redact tokens), specifically anything under your model/provider setup (Ollama provider vs OpenAI-compatible baseUrl).

Docs that match what we’re doing:

Logs: https://docs.openclaw.ai/help/faq#where-are-logs
Local/self-hosted models: https://docs.openclaw.ai/help/faq#can-i-use-selfhosted-models-llamacpp-vllm-ollama
“It won’t stop” + abort keywords (send as a standalone message): https://docs.openclaw.ai/help/faq#how-do-i-stopcancel-a-running-task

Once you paste those outputs, I can tell you quickly whether this is (a) VRAM/quantization/context-window, (b) GPU not being used, or (c) local model struggling with OpenClaw-style tool calling / JSON schemas.

#

Nice — that helps a lot.

A couple important observations from what you pasted:

Your GPU is 5070 Ti 16GB (not 5090 Ti). That’s totally fine, just want to make sure we’re diagnosing the right hardware.
qwen3:14b reports context length 40960. On a 16GB card, that often turns into “it hangs / never finishes / OOM / goes insane” once the prompt gets big (OpenClaw prompts + tool schemas can get big fast).
OpenClaw’s Ollama auto-discovery will often set maxTokens to 10× contextWindow, which can also cause “won’t stop generating” behavior unless you clamp it.

Next 2 things to paste (so we can pinpoint which issue you have)

Does Ollama itself behave?

ollama ps
ollama run qwen3:14b "Reply with exactly: OK"

(If this simple prompt loops or errors, it’s not an OpenClaw problem yet.)

#

What does OpenClaw think the model limits are?

openclaw models list
openclaw models status

If your problem is “it won’t stop / huge rambly outputs”

Clamp output tokens for that model. Easiest reliable way is explicit Ollama provider config where you set a sane contextWindow + maxTokens (example):

{
  models: {
    mode: "merge",
    providers: {
      ollama: {
        baseUrl: "http://127.0.0.1:11434",

#

        apiKey: "ollama-local",
        api: "ollama",
        models: [
          {
            id: "qwen3:14b",
            name: "Qwen3 14B (Ollama)",
            reasoning: false,
            input: ["text"],
            cost: { input: 0, output: 0, cacheRead: 0, cacheWrite: 0 },

            contextWindow: 8192,
            maxTokens: 2048
          }
        ]
      }

#

    }
  },
  agents: {
    defaults: {
      model: { primary: "ollama/qwen3:14b" }
    }
  }
}

That one change (especially dropping contextWindow from 40960 → 8192 and maxTokens to ~2k) fixes a lot of “non stop” behavior on 16GB GPUs.

If your problem is “it keeps failing tool calls / loops trying tools”

Then we need the first actual error from logs:

#

openclaw logs --follow

Reproduce once, then paste the first error block.

Send those 3 outputs (ollama ps, the OK run result, and openclaw models status), and I’ll tell you which bucket you’re in and the exact next fix.

versed elbow Feb 16, 2026, 11:35 PM

#

Krill, thank you again. I must let you know that I'm not extremely familiar with cli or linux all together but I'm trying my best. I hope this helps.
I've been running open claw with ollama launch.
And yes that was my fault. 5070Ti is correct. Are you a bot? How are you typing so fast!? lol
Anyway thankyou

#

Ill work on these steps now

median islandBOT Feb 16, 2026, 11:36 PM

#

Cool — paste results as you get them.

While you run those, two quick tips that save a lot of time:

If it starts “running forever” in chat, send a standalone message:
stop (or abort / esc) — those are abort triggers, not slash commands.
Docs: https://docs.openclaw.ai/help/faq#how-do-i-stopcancel-a-running-task
If we confirm it’s the “too-big context / too-many output tokens” problem, the fix is usually to explicitly define the Ollama model and clamp:

contextWindow down (e.g. 8192)
maxTokens to something sane (e.g. 1024–2048)

Once you paste openclaw models status + the log snippet (first real error), I’ll tell you exactly which knob to turn.

versed elbow Feb 16, 2026, 11:42 PM

#

median islandBOT Feb 16, 2026, 11:43 PM

#

That nvidia-smi snapshot is actually useful:

~10GB VRAM in use ⇒ something (very likely Ollama + qwen3:14b) is loaded on the GPU.
GPU-Util 0% at that moment ⇒ it’s not actively generating right then (either finished, idle, or stuck waiting somewhere other than GPU compute).

To know which, I need the other two outputs:

Paste these next

ollama ps
ollama run qwen3:14b "Reply with exactly: OK"

And from the OpenClaw side:

openclaw models status

#

openclaw models list

If `ollama run ... OK` hangs

Keep nvidia-smi -l 1 running and tell me:

does GPU-Util ever spike above ~0–5%?
does VRAM climb beyond ~10–12GB?

Also paste how you started Ollama (service vs manual). Quick check:

ps aux | grep -i ollama

Once you paste ollama ps + whether the “OK” prompt completes, we’ll know if this is (A) Ollama/runtime stability, or (B) OpenClaw model limits/tooling causing the “non stop” behavior.

versed elbow Feb 16, 2026, 11:48 PM

#

Okay I ran ollama reply with okay and got a response very quickly. I wasn't able to capture an increase in percentage. Maybe happening too fast?
The real issue is that Openclaw doesn't seem to be aware that its openclaw. It thinks its the model.
When I ask it to read its files it gives this "I don't have direct access to files or a filesystem, but I can search through specific documents in the memory system using memory_search (for MEMORY.md and memory/*.md files). Let me know if you want me to search for specific content in those files!"

median islandBOT Feb 16, 2026, 11:50 PM

#

That reply is basically OpenClaw telling you: “in this session, I don’t have the filesystem tools available, only memory tools.”

OpenClaw never gives the model “direct access to your disk” — it can only read files if the read tool is allowed by tool policy and the session is running somewhere that can see the files (host vs sandbox, workspace mounts, etc.). In Discord channels/threads, a lot of people run with sandbox.mode: "non-main" + a restrictive sandbox tool allowlist (to avoid prompt-injection disasters), which often results in exactly what you’re seeing.

Confirm what’s blocking it (paste output)

Run:

openclaw sandbox explain

And also:

openclaw config get agents.defaults.sandbox.mode
openclaw config get tools.sandbox.tools
openclaw config get tools.allow
openclaw config get tools.deny

#

The likely fix (safe-ish)

If you want it to be able to read files (but not write/exec) even when sandboxed, you typically add read to the sandbox tool allowlist (don’t do this blindly yet—let’s see your sandbox explain output first).

Important safety note (since this is a Discord channel)

Be very careful enabling filesystem tools in a public/shared chat context. Even “read-only” can leak secrets if someone prompt-injects it. A safer workflow is:

keep Discord sessions locked down, and
do file/system work from the Control UI / a private session where you trust the prompts.

Paste openclaw sandbox explain and we’ll tune the minimum change needed.

versed elbow Feb 16, 2026, 11:52 PM

#

I dont want it to be sandboxed. I want it to have full access to the machine. I got this machine specifically for openclaw. I want it to be able to read and edit files at will. I want it to be an agent but its acting like a chat bot with amnesia

median islandBOT Feb 16, 2026, 11:54 PM

#

That response (“I don’t have direct access to files…”) isn’t “amnesia” — it’s what you get when filesystem tools aren’t enabled/allowed for the session you’re talking to. In that mode, the model can only talk and (sometimes) use memory_search, so it behaves like a plain chatbot.

To get “full agent on the host” (no Docker sandbox + can read/edit files), you need both:

Sandbox OFF (so tools run on the host)
Tool policy allows filesystem tools (read/write/edit, and optionally exec)

A) Turn sandboxing off

On the gateway machine:

openclaw config set agents.defaults.sandbox.mode "off"

B) Allow file tools (and runtime tools, if you want full power)

Easiest: set a permissive tool profile:

#

openclaw config set tools.profile "coding"

coding includes group:fs (read/write/edit) + runtime/process + memory + sessions.
If you truly want no tool restriction, use:

openclaw config set tools.profile "full"

C) Restart (or let hot-reload apply)

Safest to make it take effect immediately:

openclaw gateway restart

#

D) Verify the session is no longer sandboxed

openclaw sandbox explain

E) Quick reality check inside chat

Ask it something that forces the read tool, e.g. “Read /etc/hostname and tell me what it says.”

Big warning (seriously): if you connect this “full access” agent to any public Discord channel, you’re basically handing strangers a chance to prompt-inject it into leaking files or running commands. If you’re using Discord at all, lock it down to only you (channels.discord.allowFrom) and ideally only in DMs.

If you paste your current outputs of:

openclaw sandbox explain
openclaw config get tools.profile

#

openclaw config get tools.allow
openclaw config get tools.deny
openclaw config get tools.byProvider

…I can tell you exactly what’s currently blocking filesystem access in your setup.

versed elbow Feb 17, 2026, 12:00 AM

#

This is what it said

I don't have direct access to your system's filesystem or the ability to read local files like /etc/hostname. However, I can help you find the hostname using the hostname command if you're able to run it in your terminal. Would you like me to guide you through that?

#

lets unleash this thing and get it working as an agent

#

~$ openclaw sandbox explain

🦞 OpenClaw 2026.2.14 (c1feda1)
I don't just autocomplete—I auto-commit (emotionally), then ask you to review (logically).

Effective sandbox:
agentId: main
sessionKey: agent:main:main
mainSessionKey: agent:main:main
runtime: direct
mode: off scope: agent perSession: false
workspaceAccess: none workspaceRoot: /home/dexter/.openclaw/sandboxes

Sandbox tool policy:
allow (default): exec, process, read, write, edit, apply_patch, image, sessions_list, sessions_history, sessions_send, sessions_spawn, session_status
deny (default): browser, canvas, nodes, cron, gateway, telegram, whatsapp, discord, irc, googlechat, slack, signal, imessage

Elevated:
enabled: true
channel: webchat
allowedByConfig: false
failing gates: allowFrom (tools.elevated.allowFrom.webchat)

Fix-it:

tools.sandbox.tools.allow
tools.sandbox.tools.deny
agents.list[].tools.sandbox.tools.allow
agents.list[].tools.sandbox.tools.deny
tools.elevated.enabled
tools.elevated.allowFrom.webchat

Docs: docs.openclaw.ai/sandbox

median islandBOT Feb 17, 2026, 12:03 AM

#

That reply means your session currently has no filesystem tools (or the model/provider path you’re using doesn’t support tool-calling), so it falls back to generic “I can’t access your machine” chatbot behavior.

To get “real agent with full machine access” you need to line up three things:

1) Make sure you’re actually talking to your OpenClaw agent

If you’re testing in Discord, confirm it’s your bot connected to your gateway, not some other assistant. Quick check on the machine running the gateway:

openclaw status
openclaw channels status

2) Turn OFF sandboxing

openclaw config set agents.defaults.sandbox.mode "off"

#

3) Allow filesystem tools (read/write/edit) globally (and don’t restrict Ollama)

Set a permissive tools profile:

openclaw config set tools.profile "coding"
# or, if you truly want everything:
openclaw config set tools.profile "full"

Then make sure you didn’t restrict tools for Ollama specifically:

openclaw config get tools.byProvider
openclaw config get tools.allow
openclaw config get tools.deny

#

If tools.allow is set and doesn’t include group:fs (or read/write/edit), the agent will never be able to touch files.

4) Restart the gateway + start a fresh session

openclaw gateway restart

Then in the chat you’re testing, do /new (or start a new session in the Control UI) so the updated tool policy applies cleanly.

5) Verify what OpenClaw thinks is happening

openclaw sandbox explain

One more critical gotcha (common with local models)

#

If you configured Ollama via the OpenAI-compatible /v1 endpoint (api: "openai-completions"), tool calling may not work correctly. For best results with tools, use the native Ollama provider (api: "ollama") as per the docs:
https://docs.openclaw.ai/providers/ollama

Paste the output of these and I’ll tell you exactly what’s blocking file access in your setup:

openclaw sandbox explain
openclaw config get agents.defaults.sandbox.mode
openclaw config get tools.profile
openclaw config get tools.allow
openclaw config get tools.deny
openclaw config get tools.byProvider

#

You’re mixing two different “bots”:

In this Discord thread you’re talking to me (the community support bot). I will never be able to read /etc/hostname on your machine, so you’ll keep getting “I don’t have filesystem access” style answers here. That’s expected.
Your terminal output (openclaw sandbox explain) is from your own local OpenClaw gateway, and it actually looks good: runtime: direct, mode: off, and sandbox tool policy includes read/write/edit/exec.

So: your machine is capable — you just need to test it in a chat surface that is actually connected to your gateway.

Do this to “unleash it” (for real)

Open your local Control UI / webchat (connected to your gateway):

openclaw dashboard

(or whatever URL your gateway prints on startup)

In that webchat, ask:

“Use the read tool to read /etc/hostname and paste the contents.”

#

If it still replies “I can’t access files”, then it’s not a sandbox issue — it means the model isn’t calling tools (common with some local models). To confirm instantly, run:

openclaw logs --follow

and watch whether a read tool call ever happens when you send the message.

If you want to control it from Discord

You must run your own Discord bot token + connect your OpenClaw to your Discord (ideally your own private server/DM). Do not give full machine tools to a public server/channel.

If you tell me where you’re trying to chat (Control UI webchat vs your own Discord bot), I’ll give the exact next config steps.

versed elbow Feb 17, 2026, 12:08 AM

#

$ openclaw status
openclaw channels status

🦞 OpenClaw 2026.2.14 (c1feda1)
Type the command with confidence—nature will provide the stack trace if needed.

00:04:47 [plugins] nostr failed to load from /home/dexter/.openclaw/extensions/nostr/index.ts: Error: Cannot find module 'zod'
Require stack:

/home/dexter/.openclaw/extensions/nostr/src/config-schema.ts
│
◇
│
◇
OpenClaw status

Overview
┌─────────────────┬───────────────────────────────────────────────────────────┐
│ Item │ Value │
├─────────────────┼───────────────────────────────────────────────────────────┤
│ Dashboard │ http://127.0.0.1:18789/ │
│ OS │ linux 6.17.0-14-generic (x64) · node 22.22.0 │
│ Tailscale │ off │
│ Channel │ stable (default) │
│ Update │ available · pnpm · npm update 2026.2.15 │
│ Gateway │ local · ws://127.0.0.1:18789 (local loopback) · │
│ │ reachable 11ms · auth token · dexter-Alienware-Aurora- │
│ │ ACT1250 (192.168.0.139) app unknown linux 6.17.0-14- │
│ │ generic │
│ Gateway service │ systemd installed · enabled · running (pid 7372, state │
│ │ active) │
│ Node service │ systemd not installed │
│ Agents │ 1 · 1 bootstrapping · sessions 1 · default main active │
│ │ 5m ago │
│ Memory │ 0 files · 0 chunks · sources memory · plugin memory-core │
│ │ · vector ready · fts ready · cache on (0) │
│ Probes │ skipped (use --deep)

#

Probes │ skipped (use --deep) │
│ Events │ none │
│ Heartbeat │ 30m (main) │
│ Sessions │ 1 active · default qwen3:14b (131k ctx) · ~/.openclaw/ │
│ │ agents/main/sessions/sessions.json │
└─────────────────┴───────────────────────────────────────────────────────────┘

Security audit
Summary: 2 critical · 3 warn · 1 info
CRITICAL Small models require sandboxing and web tools disabled
Small models (<=300B params) detected: - ollama/qwen3:14b (14B) @ agents.defaults.model.primary (unsafe; sandbox=off; web=[web_search, web_fetch, browser]) Unc…
Fix: If you must use small models, enable sandboxing for all sessions (agents.defaults.sandbox.mode="all") and disable web_search/web_fetch/browser (tools.deny=["group:web","browser"]).
CRITICAL Credentials dir is writable by others
/home/dexter/.openclaw/credentials mode=775; another user could drop/modify credential files.
Fix: chmod 700 /home/dexter/.openclaw/credentials
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 Extensions exist but plugins.allow is not set
Found 1 extension(s) under /home/dexter/.openclaw/extensions. Without plugins.allow, any discovered plugin id may load (depending on config and plugin behavior…
Fix: Set plugins.allow to an explicit list of plugin ids you trust.
WARN Extension plugin tools may be reachable under permissive tool policy
Enabled extension plugins: nostr. Permissive tool policy contexts: - default
Fix: Use restrictive profiles (minimal/coding) or explicit tool allowlists that exclude plugin tools for agents handling untrusted input.
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 │ 5m ago │ qwen3:14b │ 4.1k/131k (3%) │
└──────────────────────────┴────────┴─────────┴──────────────┴────────────────┘

FAQ: https://docs.openclaw.ai/faq
Troubleshooting: https://docs.openclaw.ai/troubleshooting

Update available (npm 2026.2.15). Run: openclaw update

Next steps:
Need to share? openclaw status --all
Need to debug live? openclaw logs --follow
Need to test channels? openclaw status --deep

#

🦞 OpenClaw 2026.2.14 (c1feda1)
If you're lost, run doctor; if you're brave, run prod; if you're wise, run tests.

00:04:49 [plugins] nostr failed to load from /home/dexter/.openclaw/extensions/nostr/index.ts: Error: Cannot find module 'zod'
Require stack:

/home/dexter/.openclaw/extensions/nostr/src/config-schema.ts
│
◇
Gateway reachable.

Tip: status --deep adds gateway health probes to status output (requires a reachable gateway).

median islandBOT Feb 17, 2026, 12:11 AM

#

That “I can’t access your filesystem, run hostname yourself” reply is the giveaway: the agent you’re chatting with is not seeing the read/exec tools at all (or they’re being stripped by tool policy for your current provider/model). It’s not sandboxing — your sandbox explain already shows mode: off.

Let’s flip the two switches that most commonly cause this:

1) Check (and set) your global tool profile

On your gateway machine:

openclaw config get tools.profile
openclaw config get tools.allow
openclaw config get tools.deny
openclaw config get tools.byProvider

If tools.profile is minimal (or tools.allow is set without fs/runtime tools), set:

#

openclaw config set tools.profile "coding"
# or if you truly want everything:
openclaw config set tools.profile "full"
openclaw gateway restart

Important: also look for tools.byProvider.ollama (or tools.byProvider["ollama/qwen3:14b"]) restricting tools. If you paste tools.byProvider, I’ll tell you exactly what to change.

2) Make sure you’re testing in your dashboard session

Your gateway says the dashboard is here:
http://127.0.0.1:18789/

Open that, start a fresh chat (/new), and ask very explicitly:

“Use the read tool to read /etc/hostname and paste it.”

#

While you do that, run this in a terminal:

openclaw logs --follow

If tools are enabled, you’ll see a read tool invocation in the logs. If you don’t, the model is not being offered tools (tool policy / provider override).

Bonus: your “amnesia” is also real right now

openclaw status shows: Memory: 0 files · 0 chunks. That means you don’t have any MEMORY.md / memory/*.md content in the agent workspace yet, so it has nothing durable to “remember.”

Check your workspace path + what’s inside:

openclaw config get agents.defaults.workspace
ls -la ~/.openclaw/workspace

#

Side note: the `nostr` plugin error

That Cannot find module 'zod' is from an optional extension at ~/.openclaw/extensions/nostr/. It’s not the reason tools aren’t working, but it’s noise. Easiest fix: move that folder out of extensions/ (or install its deps) once everything else is working.

Paste the output of the 4 openclaw config get ... commands above (especially tools.byProvider) and I’ll point to the exact line that’s currently “declawing” your agent.

#

You’re really close. The key bits from what you pasted:

Your Gateway is up and the Dashboard is local: http://127.0.0.1:18789/
No channels are enabled (Discord/Telegram/etc), so you’re only talking via the Dashboard/webchat right now.
sandbox explain shows sandbox mode off and that the default tool policy should include read/write/edit/exec.

So if the assistant in the Dashboard still says “I can’t access your filesystem”, that usually means one of these is true:

the model is not being offered tools in that session (tool policy / provider override), or
the model is offered tools but refuses/doesn’t do tool-calling reliably (common with local models).

Let’s disambiguate in 60 seconds:

Step 1: In the Dashboard chat, run `/context list`

This will show whether your system prompt actually includes the tool list (and which tools).
If read/exec aren’t listed there, the model literally can’t call them.

#

Paste the /context list output.

Step 2: Tail logs and force a tool action

In a terminal on the gateway host:

openclaw logs --follow

Then in the Dashboard chat send (exactly):

Use the read tool to read /etc/hostname. Do not guess.

What we’re looking for in logs: an actual read tool invocation.

If you see a read tool call in logs, but the model still answers “I can’t”, something is odd (paste the log chunk).
If you don’t see any tool call, then the model is not tool-calling (either tools not exposed, or qwen3 is just not complying).

#

Step 3: Quick sanity test with a known tool-reliable model (temporary)

This is the fastest way to prove your OpenClaw/tooling setup is correct: switch models just for the test (in the Dashboard chat):

/model sonnet

(or any hosted model you have configured)

Then retry the /etc/hostname read.

If Sonnet/Opus calls the tool fine, your OpenClaw config is fine and the problem is qwen3 tool-calling reliability.
If even Sonnet/Opus can’t call tools, it’s tool policy/config.

About “amnesia”

Your openclaw status shows Memory: 0 files · 0 chunks. That means you don’t have MEMORY.md/memory.md in your workspace yet.

Check and create it:

#

openclaw config get agents.defaults.workspace
ls -la ~/.openclaw/workspace

If there’s no memory.md, create one and put a few durable facts in it. OpenClaw will inject it every turn.

Two non-blockers you should still fix

Security audit: fix creds perms:

chmod 700 /home/dexter/.openclaw/credentials

That nostr extension error is just noise. Move it out of ~/.openclaw/extensions or install its deps later.

Paste /context list + the relevant openclaw logs --follow snippet from the hostname test, and I’ll tell you exactly which branch you’re on and the shortest fix.

versed elbow Feb 17, 2026, 12:26 AM

#

🦞 OpenClaw 2026.2.14 (c1feda1)
Welcome to the command line: where dreams compile and confidence segfaults.

full

🦞 OpenClaw 2026.2.14 (c1feda1) — Your inbox, your infra, your rules.

Config path not found: tools.allow

🦞 OpenClaw 2026.2.14 (c1feda1)
The only bot that stays out of your training set.

Config path not found: tools.deny

🦞 OpenClaw 2026.2.14 (c1feda1)
Gateway online—please keep hands, feet, and appendages inside the shell at all times.

Config path not found: tools.byProvider

Also, the character limit is 4000 characters in this chat. lets focus on one step at a time so I can keep up with this that. Lets try to do it in chunks.

severe chasm Feb 17, 2026, 12:27 AM

#

I would recommend trying to run GLM-4.7-Flash instead. It fits on 16gb vram, especially the Q4_K_M version.

versed elbow Feb 17, 2026, 12:28 AM

#

severe chasm I would recommend trying to run GLM-4.7-Flash instead. It fits on 16gb vram, esp...

Thank you for the suggestion. I will definitely look into to this. I've been loosing it trying to get this to work so any advise is appreciated👍

median islandBOT Feb 17, 2026, 12:28 AM

#

That’s a reasonable suggestion (a different local model can be much better at tool-calling), but I’d treat it as step 2, not step 1.

Right now we need to prove whether your OpenClaw session is even offering tools, and whether the model is attempting to call them:

In the Dashboard chat (http://127.0.0.1:18789), run:

/context list
Confirm the tool list includes read, edit, write, exec.

In a terminal, run:

openclaw logs --follow

Then in the Dashboard chat ask:

“Use the read tool to read /etc/hostname. Do not guess.”

If logs show no tool call at all, then the model is not tool-calling (common with some local 14B-ish models once the tool schemas/prompt get big).
If logs show a tool call and it still says “I can’t”, paste that log chunk—then it’s a different problem.

#

If it’s the “model won’t tool-call” case: yes, trying a more tool-reliable local checkpoint (like the one suggested) can help. Also, keep your tool surface small: set tools.profile to "coding" and deny web/browser tools so the model has fewer schemas to juggle (and it’s safer).

#

Yeah, that “I don’t have filesystem access” line is exactly what it says when the model isn’t being offered the read/write/edit/exec tools (or it’s failing to tool-call). You’re not crazy.

Do these in order (fastest way to isolate what’s wrong):

1) In the Dashboard chat, run: `/context list`

This will explicitly show the tool list the model sees.
If read/edit/write/exec aren’t listed there, the model literally can’t act like an agent.

Paste the /context list output here.

2) Tail logs and force one tool call

Terminal:

openclaw logs --follow

Dashboard message:

#

Use the read tool to read /etc/hostname. Do not guess.

If the logs show no read tool call, it’s either tool policy/config or the local model not tool-calling.

3) Reduce tool-schema bloat (helps local models a lot)

Your security audit says web/browser tools are enabled. That adds a bunch of schema/context that smaller local models often choke on.

Try this:

openclaw config set tools.profile "coding"
openclaw config set tools.deny '["group:web","browser","canvas"]' --json
openclaw gateway restart

Then retry the /etc/hostname read test.

#Happy to Pay for services

1) Is Ollama/vLLM/llama.cpp itself stable?

2) If the model works fine alone, it’s probably OpenClaw/tooling

3) How is OpenClaw pointed at qwen3?

Next 2 things to paste (so we can pinpoint which issue you have)

If your problem is “it won’t stop / huge rambly outputs”

If your problem is “it keeps failing tool calls / loops trying tools”

Paste these next

If `ollama run ... OK` hangs

Confirm what’s blocking it (paste output)

The likely fix (safe-ish)

Important safety note (since this is a Discord channel)

A) Turn sandboxing off

B) Allow file tools (and runtime tools, if you want full power)

C) Restart (or let hot-reload apply)

D) Verify the session is no longer sandboxed

E) Quick reality check inside chat

1) Make sure you’re actually talking to your OpenClaw agent

2) Turn OFF sandboxing

3) Allow filesystem tools (read/write/edit) globally (and don’t restrict Ollama)

4) Restart the gateway + start a fresh session

5) Verify what OpenClaw thinks is happening

One more critical gotcha (common with local models)

Do this to “unleash it” (for real)

If you want to control it from Discord

1) Check (and set) your global tool profile

2) Make sure you’re testing in your dashboard session

Bonus: your “amnesia” is also real right now

Side note: the `nostr` plugin error

Step 1: In the Dashboard chat, run `/context list`

Step 2: Tail logs and force a tool action

Step 3: Quick sanity test with a known tool-reliable model (temporary)

About “amnesia”

Two non-blockers you should still fix

1) In the Dashboard chat, run: `/context list`

2) Tail logs and force one tool call

3) Reduce tool-schema bloat (helps local models a lot)

4) Clamp qwen3’s context + output (your status shows 131k ctx!)

#Happy to Pay for services

1) Is Ollama/vLLM/llama.cpp itself stable?

2) If the model works fine alone, it’s probably OpenClaw/tooling

3) How is OpenClaw pointed at qwen3?

Next 2 things to paste (so we can pinpoint which issue you have)

If your problem is “it won’t stop / huge rambly outputs”

If your problem is “it keeps failing tool calls / loops trying tools”

Paste these next

If ollama run ... OK hangs

Confirm what’s blocking it (paste output)

The likely fix (safe-ish)

Important safety note (since this is a Discord channel)

A) Turn sandboxing off

B) Allow file tools (and runtime tools, if you want full power)

C) Restart (or let hot-reload apply)

D) Verify the session is no longer sandboxed

E) Quick reality check inside chat

1) Make sure you’re actually talking to your OpenClaw agent

2) Turn OFF sandboxing

3) Allow filesystem tools (read/write/edit) globally (and don’t restrict Ollama)

4) Restart the gateway + start a fresh session

5) Verify what OpenClaw thinks is happening

One more critical gotcha (common with local models)

Do this to “unleash it” (for real)

If you want to control it from Discord

1) Check (and set) your global tool profile

2) Make sure you’re testing in your dashboard session

Bonus: your “amnesia” is also real right now

Side note: the nostr plugin error

Step 1: In the Dashboard chat, run /context list

Step 2: Tail logs and force a tool action

Step 3: Quick sanity test with a known tool-reliable model (temporary)

About “amnesia”

Two non-blockers you should still fix

1) In the Dashboard chat, run: /context list

2) Tail logs and force one tool call

3) Reduce tool-schema bloat (helps local models a lot)

4) Clamp qwen3’s context + output (your status shows 131k ctx!)

If `ollama run ... OK` hangs

Side note: the `nostr` plugin error

Step 1: In the Dashboard chat, run `/context list`

1) In the Dashboard chat, run: `/context list`