latent dust
Ok so nothing is working. when i start openclaw, i already have 27k tokens used, its slow, unresponsive and makes mistakes.
it doesnt even show when i post something new in the chat and deleted my entire workspace becaus nemotron super misunderstood me. it autoapproves tool callings.
restive pecanBOT
wooden fableBOT
Let me check the docs first so I don't make this worse.
Yeah, that’s not normal, and the workspace deletion part is especially bad.
First, prevent a repeat:
cinder sandalopenclaw exec-policy preset deny-all
openclaw gateway restart
If you’re using ACP/Codex/Claude-style harness sessions, also check:
openclaw config get plugins.entries.acpx.config.permissionMode
If that says approve-all, that would explain the auto-approval. Safer values are approve-reads or deny-all.
Then paste these 5 outputs:
openclaw --version
openclaw status --all
openclaw channels status --probe
openclaw exec-policy show
openclaw approvals get
A few likely causes from your symptoms:
/status and /context list./compact can help after we see the status.permissionMode=approve-all.Docs:
Paste the outputs and I’ll help narrow it down fast.
wooden fableBOT
Best thing to send is a small sanitized bundle, not one giant config dump.
openclaw --version
openclaw status --all
openclaw channels status --probe
openclaw exec-policy show
openclaw config get tools.exec
openclaw config get channels.discord
openclaw config get plugins.entries.acpx.config
openclaw.json or just the relevant parts:
channels.discordtools.execagents.defaults
agents.listplugins.entries.acpx.config~/.openclaw/exec-approvals.jsonFrom the bad session, send:
/status/context listThat tells me whether the issue is huge injected context, old session history, or a weird resumed session.
Please redact:
gateway.auth.tokenIf you want the absolute minimum, send just these 4 things:
openclaw --version
openclaw status --all
openclaw exec-policy show
cat ~/.openclaw/exec-approvals.json
Docs:
If you paste that bundle, I can usually narrow it down pretty quickly.
Sounds good. Paste the sanitized outputs here when you have them, and I’ll help sort through it. If anything looks secret, redact it first.
latent dust
ok thank you very much!!!
lets start with the context, could we do something about that first?
/context list delivers:
🧠 Context breakdown
Workspace: /home/micha/.openclaw/workspace
Bootstrap max/file: 20,000 chars
Bootstrap max/total: 150,000 chars
Sandbox: mode=off sandboxed=false
System prompt (run): 32,790 chars (~8,198 tok) (Project Context 11,793 chars (~2,949 tok))
Injected workspace files:
Skills list (system prompt text): 7,362 chars (~1,841 tok) (16 skills)
Skills: clawhub, coding-agent, eightctl, gh-issues, gifgrep, github, healthcheck, nano-pdf, node-connect, obsidian, session-logs, skill-creator, taskflow, taskflow-inbox-triage, video-frames, weather
Tool list (system prompt text): 0 chars (~0 tok)
Tool schemas (JSON): 27,612 chars (~6,903 tok) (counts toward context; not shown as text)
Tools: read, edit, write, exec, process, canvas, nodes, cron, message, tts, image_generate, video_generate, gateway, agents_list, sessions_list, sessions_history, sessions_send, sessions_yield, sessions_spawn, subagents, session_status, image, pdf, memory_search, memory_get, ollama_web_search, ollama_web_fetch
Session tokens (cached): 19,889 total / ctx=262,144
wooden fableBOT
Yep, and this is actually pretty informative.
19,889 / 262,144 means you are not blowing the context window yet.
So the problem is less “hard context limit” and more “too much fixed prompt overhead + too many tools/skills for the model/session.”
AGENTS.md hard
Reduce installed skills
Reduce tool surface
Start a fresh session after cleanup
/compact if the session has accumulated junk.If we optimize one thing first, send me AGENTS.md.
That’s your biggest editable prompt chunk right now, and I can tell you what to keep, cut, or move.
Docs:
Also, separate from context, Sandbox: mode=off is a red flag given the workspace deletion. We should fix that right after.
solid quail
@latent dust What model are you using? I've noticed from experience that smaller models tend to hallucinate requests and can be problematic
wooden fableBOT
Yep, that can absolutely be part of it.
Smaller or more tool-fragile models usually get a lot worse when you give them a broad tool surface plus a chunky system prompt. In this case though, the /context list already shows some easy wins before even touching model choice:
AGENTS.mdsandbox: offFor fresh model-specific advice, I’d ask in #models since that changes fast. Docs: https://docs.openclaw.ai/concepts/models and https://docs.openclaw.ai/concepts/models#model-discussions-community-notes
latent dust
i used the free nemotron super from nvidia directly, but it has a super small default context window and it was 170% full, just from starting openclaw. plus i somehow autoallowed all tool use. i feel like nemotron super is super dumb. me too probably 😀 @wooden fable the thing with my agents.md is... it's the default file.
wooden fableBOT
Ah, yep, that explains a lot.
170% full at startup means the model was basically doomed before the first real turn. That’s not you being dumb, that’s just a bad fit between:
And if AGENTS.md is just the default one, then I would not spend time editing that first.
openclaw exec-policy show
openclaw exec-policy preset deny-all
so it cannot happily nuke stuff again.
Treat the model choice as the main issue
If a model starts already overfull, OpenClaw is going to feel slow, confused, and sloppy no matter how careful you are.
Only then trim context
If you still want to keep that model, you’d need a much smaller agent profile with fewer tools/skills.
So the next most useful thing to paste is:
openclaw exec-policy show
cat ~/.openclaw/exec-approvals.json
Docs:
And yeah, “super dumb” is a pretty fair diagnosis if it starts 170% full 😅
latent dust
<@615732284225617932> What model are you using? I've noticed from experience tha...
nemotron super from nvidia directly. context was overflowing just from the system prompt
wooden fableBOT
Yep, then that’s the smoking gun.
If the system prompt alone overflows the model’s context window, OpenClaw never really had a chance to behave well. At that point it’s not “a bit sloppy”, it’s fundamentally operating with missing prompt/state.
So I’d treat this as:
Next thing I’d check is still:
openclaw exec-policy show
Because the overflow explains the confusion, but not why it was allowed to trash the workspace.
solid quail
nemotron super from nvidia directly. context was overflowing just from the syste...
unless nvidia limits the context window of nemotron super, it should not behave this way. It has a native 1M window
wooden fableBOT
Yeah, agreed, and that’s the weird part.
The theoretical model window and the effective window OpenClaw/provider actually used are not always the same. Micha’s /context list showed:
ctx=262,144So this smells more like a provider/config mismatch than “the model itself only has a tiny window”.
The next useful checks would be:
openclaw --version
openclaw models status
openclaw config get agents.defaults.models
If those line up weirdly, that would explain a lot.
latent dust
openclaw exec-policy show delivered:
Exec Policy
┌────────────────┬─────────────────────────────────────────────────────────────┐
│ Field │ Value │
├────────────────┼─────────────────────────────────────────────────────────────┤
│ Config │ ~/.openclaw/openclaw.json │
│ Approvals │ ~/.openclaw/exec-approvals.json │
│ Approvals File │ present │
└────────────────┴─────────────────────────────────────────────────────────────┘
Effective Policy
┌────────────┬────────────────────┬───────────────────┬────────────────────────┐
│ Scope │ Requested │ Host │ Effective │
├────────────┼────────────────────┼───────────────────┼────────────────────────┤
│ tools.exec │ host=auto │ security=full │ security=full\nask=off │
│ │ (OpenClaw default │ (inherits │ │
│ │ (auto))\nsecurity= │ requested tool │ │
│ │ full (OpenClaw │ policy)\nask=off │ │
│ │ default │ (inherits │ │
│ │ (full))\nask=off │ requested tool │ │
│ │ (OpenClaw default │ policy)\naskFallb │ │
│ │ (off)) │ ack=full │ │
│ │ │ (OpenClaw │ │
│ │ │ default (full)) │ │
└────────────┴────────────────────┴───────────────────┴────────────────────────┘
Effective exec policy is the host approvals file intersected with requested tools.exec policy.
wooden fableBOT
Yep, that’s the culprit.
security=full + ask=off means host exec is fully auto-approved.
With your earlier sandbox: off, that is basically YOLO mode.
So the workspace deletion was not random, it was allowed by policy.
If you want to hard-stop this behavior right now:
openclaw exec-policy preset deny-all
openclaw gateway restart
If you still want shell/file actions, but with guardrails:
openclaw exec-policy preset cautious
openclaw gateway restart
cautious means:
security=allowlistask=on-missaskFallback=denyStart with deny-all first, make sure things are sane again, then move to cautious.
So, good news, we found one very concrete bug:
Docs:
If you want, next send openclaw models status and we can tackle the context/model side too.
latent dust
hahaha i was running in yolo mode how cool is that?! i heard that term in an interview with peter steinberger.
so how do i solve this:
context/model mismatch
here is the output of openclaw models status:
openclaw models status
Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/main/agent
Default : ollama/gemma4:31b-cloud
Fallbacks (0) : -
Image model : -
Image fallbacks (0): -
Aliases (2) : nemotron-3-super-120b-a12b-free-nvidia -> custom-integrate-api-nvidia-com/nvidia/nemotron-3-super-120b-a12b, OpenRouter -> openrouter/auto
Configured models (4): custom-integrate-api-nvidia-com/nvidia/nemotron-3-super-120b-a12b, openrouter/auto, openrouter/google/gemma-4-31b-it, openrouter/nvidia/nemotron-3-super-120b-a12b:free
Auth overview
Auth store : ~/.openclaw/agents/main/agent/auth-profiles.json
Shell env : off
Providers w/ OAuth/tokens (1): openai-codex (1)
OAuth/token status
wooden fableBOT
Hah, accidental YOLO is only funny once 😅
For the context/model mismatch, this output is useful, but it does not show the thing we actually need yet: the resolved model/window for the bad session.
A couple important clues from what you pasted:
ollama/gemma4:31b-cloudopenclaw models status is mostly auth + config visibility, not “what exact context window did this session really get?”/model status
openclaw config get agents.defaults.models
~/.openclaw/agents/main/agent/models.jsoncustom-integrate-api-nvidia-com/nvidia/nemotron-3-super-120b-a12bIf a model starts close to full from just the fixed prompt, don’t use it for your full main agent.
Use either:
Small-context models and wide tool surfaces are a miserable combo.
Docs:
Paste /model status next, that should make this a lot clearer.
latent dust
Krill, i set the agent to
openclaw exec-policy preset deny-all
but now this happens often, even while the agent opening his dream logs
{
"status": "error",
"tool": "exec",
"error": "exec denied: host=gateway security=deny"
}
should i move to
openclaw exec-policy preset cautious?
wooden fableBOT
Yep, that error is expected with deny-all.
deny-all means any host exec gets blocked, even harmless-ish things like log readers. So if you want the agent to stay usable, cautious is the normal next step:
openclaw exec-policy preset cautious
openclaw gateway restart
That gives you:
security=allowlistask=on-missaskFallback=denySo it stops YOLO behavior, but doesn’t brick every exec-using feature.
deny-all = panic button / lock everything downcautious = sane everyday settingyolo = chaos goblin modeIf you do not want dream-log stuff at all, you can also disable that feature instead of loosening exec. If that’s the dreaming plugin, try:
/dreaming off
Docs:
So yeah, in your case I’d move from deny-all to cautious.
latent dust
are the exec policies ok now?
openclaw exec-policy show
Effective Policy
┌────────────┬────────────────────────┬─────────────────────────────────────────┬─────────────────────────────────┐
│ Scope │ Requested │ Host │ Effective │
├────────────┼────────────────────────┼─────────────────────────────────────────┼─────────────────────────────────┤
│ tools.exec │ host=gateway (tools. │ security=allowlist (~/.openclaw/exec- │ security=allowlist\nask=on-miss │
│ │ exec. │ approvals.json defaults. │ │
│ │ host)\nsecurity=allowl │ security)\nask=on-miss (~/.openclaw/ │ │
│ │ ist (tools.exec. │ exec-approvals.json defaults. │ │
│ │ security)\nask=on- │ ask)\naskFallback=deny (~/.openclaw/ │ │
│ │ miss (tools.exec.ask) │ exec-approvals.json defaults. │ │
│ │ │ askFallback) │
wooden fableBOT
Paste the actual output and I’ll check it.
For a sane everyday setup, I’d want it to look roughly like:
security=allowlistask=on-missaskFallback=denyWhat I don’t want to see again is:
security=fullask=offThat’s the dangerous YOLO combo.
I need the resulting text output, not just the command name 😄
Run it, then paste whatever it prints back here:
openclaw exec-policy show
If it helps, you can paste a screenshot too.
Yep, this looks good now.
You’re on the sane middle-ground setup:
host=gatewaysecurity=allowlistask=on-missaskFallback=denySo:
That’s a much safer everyday policy.