Stuck at the start: Why isn't Openclaw saving my IDENTITY.md and USER.md?

[neat pulsar]

I installed Openclaw on Ubuntu. Followed all instructions, put openrouter with few different models and also lm-studio local ones. Then when first session starts, I gave description of myself and how I wanted my bot to behave. But it didn't save this to IDENTITY.md nor USER.md. When I try to command it to write things down i just see tool calls from LLM but nothing gets written.

Message like this.

minimax:tool_call
<invoke name="exec">
<parameter name="command">cat > /home/davor/.openclaw/workspace/IDENTITY.md <<
'EOF'

IDENTITY.md

• Name: AI...
  EOF</parameter>
  </invoke>
  <invoke name="exec">
  <parameter name="command">cat > /home/user/.openclaw/workspace/USER.md <<
  'EOF'

USER.md

• Name: bla...
  EOF</parameter>
  </invoke>
  </minimax:tool_call>

I tried also with Sonnet and few other models I get the same. I tried many things but nothing works. It just can't write in a file anywhere.
Please help

[muted turtle]

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

[little galleon]

That symptom is very often “the tools are running in a Docker sandbox, but you’re looking at the host workspace”.

When sandboxing is enabled, exec/read/write/edit run inside the container. And by default the sandbox does not mount your real agent workspace (workspaceAccess: "none"), so any files the model writes won’t show up in ~/.openclaw/workspace/… on the host. (Also: Discord threads are typically non-main sessions, so if your sandbox mode is "non-main", Discord will be sandboxed by default.)

Docs: https://docs.openclaw.ai/gateway/sandboxing (see Workspace access + Modes)

1) Quick confirm (paste outputs)

Run these on the Ubuntu box where the Gateway runs:

openclaw --version
openclaw sandbox explain
openclaw gateway status
openclaw status --all

openclaw sandbox explain will tell us immediately if you’re in mode: non-main|all and what workspaceAccess is.

2) If sandbox is the cause: pick a fix

Option A (simplest while onboarding): disable sandboxing
In ~/.openclaw/openclaw.json set:

agents: { defaults: { sandbox: { mode: "off" } } }

Then:

openclaw gateway restart

Option B (keep sandboxing, but allow real workspace writes):
Set:

agents: { defaults: { sandbox: { workspaceAccess: "rw" } } }

Then restart the gateway.

That mounts the agent workspace into the container at /workspace, so edits persist.

3) One more thing in your snippet

Your model is trying to write to guessed absolute paths like /home/davor/... and even /home/user/.... In OpenClaw you generally want tools to write to relative workspace paths (e.g. IDENTITY.md, USER.md) or /workspace/... when sandboxed. Absolute /home/<you> paths are a common fail when sandboxing is on.

If you paste the sandbox explain output, I can tell you exactly which config line to change for your setup.

[neat pulsar]

◇ Doctor warnings ────────────────────────────────────────────────────────╮
│ │
│ - channels.telegram.groupPolicy is "allowlist" but groupAllowFrom (and │
│ allowFrom) is empty — all group messages will be silently dropped. │
│ Add sender IDs to channels.telegram.groupAllowFrom or │
│ channels.telegram.allowFrom, or set groupPolicy to "open". │
│ │
├──────────────────────────────────────────────────────────────────────────╯
Effective sandbox:
agentId: main
sessionKey: agent:main:main
mainSessionKey: agent:main:main
runtime: direct
mode: off scope: agent perSession: false
workspaceAccess: rw workspaceRoot: /home/davor/.openclaw/sandboxes

Sandbox tool policy:
allow (default): exec, process, read, write, edit, apply_patch, image, sessions_list, sessions_history, sessions_send, sessions_spawn, subagents, 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

[little galleon]

Nice, that output is the key — and it also means my earlier “you’re sandboxed in Docker” guess is not what’s happening here:

• mode: off
• runtime: direct

So tools should be running on the host.

At this point there are 3 common causes left, and we can separate them quickly.

1) Are you looking at the same workspace the Gateway is actually using?

Please paste the workspace path from:

openclaw status --all
openclaw gateway status

In particular, openclaw gateway status will tell you if Config (cli) and Config (service) differ. If the service is using a different config/state dir than your shell, the bot may be writing somewhere else (or failing) and you’ll never see it in /home/davor/.openclaw/workspace.

FAQ section (re: config cli vs service mismatch):
https://docs.openclaw.ai/help/faq

2) Is exec actually executing, or are you just seeing “tool_call text”?

In the chat where this fails, ask the bot to run something super simple:

• “Run exec with: pwd; whoami; ls -la ~/.openclaw and paste the output.”

If you don’t get command output, then the provider/model path you’re using is emitting tool-call markup but OpenClaw isn’t actually executing it (tool-calling compatibility issue).

If you do get output, we’ll immediately see what user it runs as + what filesystem it can see.

3) Does the target directory even exist / is it writable?

On the Ubuntu box (same user running the gateway), run:

ls -la /home/davor/.openclaw/workspace
echo "hi" > /home/davor/.openclaw/workspace/_write_test.txt
ls -la /home/davor/.openclaw/workspace/_write_test.txt

• If this fails → it’s just a permissions/path problem.
• If this works → then the bot’s exec is either (a) not running, or (b) running under a different user/home than you think (Step 2 will show that).

If you paste openclaw gateway status + the result of that pwd/whoami/ls exec test, I can tell you exactly which of the three it is and what to change next.

[neat pulsar]

using

openclaw status --all
openclaw gateway status

🛠 System Overview

Version: 2026.3.2 (Latest/Stable)

Environment: Linux 6.8.0-101 (x64) with Node 22.22.1.

Status: The Gateway is active and running under systemd (PID 10251).

Connectivity: Operating on local loopback (127.0.0.1:18789). Tailscale is installed but currently OFF.

🤖 Agents & Skills

Active Agents: 1 total (main). It is currently bootstrapping and has 2 sessions active (last seen 9h ago).

Skills: 7 eligible skills detected; 0 missing.

📡 Communication Channels

Telegram: Enabled and OK.

Critical Warning: The groupPolicy is set to "allowlist", but your groupAllowFrom list is empty.

    Result: All incoming group messages are currently being silently dropped.

    Fix: Add authorized IDs to the allowlist or change the policy to "open".

🔍 Diagnosis & Troubleshooting

Port Conflict: The system notes Port 18789 is already in use by PID 10251 (the gateway itself). This is normal if the service is already running, but it will prevent a second instance from starting.

Log Location: /tmp/openclaw/openclaw-2026-03-07.log

Security: A deep security audit is recommended (openclaw security audit --deep).

[little galleon]

Your openclaw sandbox explain + the behavior you’re seeing lines up with a very specific gotcha in 2026.3.x:

What’s happening

1. The model is trying to write files via exec using shell redirection (cat > … << 'EOF' …).

2. But per the docs, exec.host defaults to sandbox:

• If sandboxing is off, and host=sandbox is effectively selected, exec fails closed (so you see the tool call, but nothing runs).

Source: https://docs.openclaw.ai/tools/exec (see “host defaults to sandbox” and the fail-closed note)

3. Even if you switch exec to run on the gateway, there’s another issue:

• In security=allowlist mode, redirections (>, <<) are rejected / unsupported, so that cat > file <<EOF approach won’t work reliably anyway. (Same doc, “Redirections remain unsupported”.)

The fix (recommended)

Tell OpenClaw to run exec on the gateway host (since you’re not using sandboxing):

In ~/.openclaw/openclaw.json:

{
  tools: {
    exec: {
      host: "gateway"
    }
  }
}

Then restart:

openclaw gateway restart

And for writing USER.md / IDENTITY.md

Don’t use exec redirection for this. Use the file tools (write / edit) which are in group:fs.

If you just want to get unstuck immediately, run:

openclaw setup

This will seed missing workspace bootstrap files (including USER.md / IDENTITY.md) without playing shell games. Docs: https://docs.openclaw.ai/concepts/agent-workspace

---

If you paste the raw output of openclaw gateway status (not the summary), I can tell you what tools.exec.security/ask is currently set to as well — but tools.exec.host: "gateway" is the big missing piece here.

[neat pulsar]

Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-03-07.log
Command: /usr/bin/node /home/davor/.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 13374, state active, sub running, last exit 0, reason 0)
RPC probe: ok

Listening: 127.0.0.1:18789

[little galleon]

Perfect — your gateway status confirms the service is healthy and using the same config as your CLI. So this really comes down to how tools are being executed.

Root cause

In 2026.3.2, the exec tool’s default target is host=sandbox (docs). If you haven’t enabled sandboxing, exec will fail closed instead of “silently running on the host”.

So your model keeps emitting:

<invoke name="exec"> … </invoke>

…but nothing actually runs, hence no files written.

Source: https://docs.openclaw.ai/tools/exec
(“host defaults to sandbox” + “If sandboxing is off … exec now fails closed …”)

Fix (recommended)

Set exec to run on the gateway host:

Option A: edit ~/.openclaw/openclaw.json

Add:

{
  tools: {
    exec: { host: "gateway" }
  }
}

then:

openclaw gateway restart

Option B: via CLI (if you prefer)

openclaw config set tools.exec.host gateway
openclaw gateway restart

Important follow-up: don’t use cat > file <<EOF via exec

Even after exec works, your model’s specific command style (>, <<) is fragile because in allowlist mode redirections are rejected/unsupported (same exec docs).

For writing USER.md / IDENTITY.md, the bot should use the write tool (group:fs), not shell redirection.

Quick test after restart

In chat, ask it to run:

• exec: whoami
• then: “use the write tool to create _tool_test.txt with text ok”

If those work, your workspace writes are fixed and we can then have it rewrite USER.md / IDENTITY.md properly (with write, using relative paths like USER.md, IDENTITY.md).

If exec: whoami still produces no output after the config change, paste the relevant lines from /tmp/openclaw/openclaw-2026-03-07.log right after the attempted tool call.

[neat pulsar]

i get this exec: whoami

minimax:tool_call
<invoke name="exec">
<parameter name="command">whoami</parameter>
</invoke>
</minimax:tool_call>

use the write tool to create _tool_test.txt with text ok

minimax:tool_call
<invoke name="exec">
<parameter name="command">echo "ok" >
/home/davor/.openclaw/workspace/_tool_test.txt</parameter>
</invoke>
</minimax:tool_call>

[little galleon]

What you pasted is very telling:

• You asked for exec: whoami → you only see the minimax:tool_call … <invoke name="exec">whoami</invoke> block, but you never get a tool result (it should print davor or similar).
• You asked it to use the write tool → it still tried to do exec with echo "ok" > … (shell redirection).

So right now you’re stuck in the worst combo:

1. The model keeps choosing exec for file writes (with > / <<), and
2. Your exec calls aren’t actually completing / returning output (likely blocked by host targeting + approvals policy).

Also note: even when exec does run, redirections (>, <<) are not supported in allowlist mode, so using exec to write files is the wrong approach long-term. Source: https://docs.openclaw.ai/tools/exec

Fastest way to get unstuck: force “write/edit”, disable “exec”

Do this temporarily so the model must use the file tools instead of shell hacks:

Edit ~/.openclaw/openclaw.json and set:

{
  tools: {
    profile: "coding",      // includes group:fs (read/write/edit)
    deny: ["group:runtime"] // removes exec/process/bash so it can't try redirections
  }
}

Then restart:

openclaw gateway restart

Now ask the bot again: “Create USER.md …” / “Update IDENTITY.md …”
It should be forced to use write/edit (no more exec cat > …).

Docs for tool profiles/groups: https://docs.openclaw.ai/tools

If you want exec later

We can re-enable it after you’ve got the workspace seeded, but then you’ll want to:

• set tools.exec.host: "gateway" (since you’re not using sandboxing), and
• configure exec approvals appropriately (otherwise commands may just get denied/pending).

But for your original goal (persisting USER/IDENTITY), disabling runtime tools and using file tools is the clean fix.

If you try the config above and it still prints tool_calls without results, paste the last ~50 lines of /tmp/openclaw/openclaw-2026-03-07.log right after a “whoami” attempt — that will show exactly what’s blocking execution.

[neat pulsar]

ok now it works, explain what to do next so that I can use openclaw, if I return how it was it wont be able to do anything right

[little galleon]

Now you’re in the “safe but crippled” mode: denying group:runtime forces the bot to use read/write/edit, which is why it finally started persisting files.

To get back to a usable setup, you want to re-enable exec, but with the two missing pieces that caused “tool calls but nothing happens” before:

1. exec was effectively targeting sandbox (which you don’t have enabled), and/or
2. host exec was getting blocked by approvals.

Here’s the sane way forward.

Recommended next config (usable + safe)

Keep the coding toolset, re-enable runtime tools, and make exec run on the gateway host with approvals:

{
  tools: {
    profile: "coding",

    // remove your temporary deny of group:runtime
    // deny: ["group:runtime"],

    exec: {
      host: "gateway",
      security: "allowlist",
      ask: "on-miss"
    }
  }
}

Then:

openclaw gateway restart

What changes after this?

• The bot can run exec again, but anything not allowlisted will require approval (“on-miss”).
• This avoids the “it tries exec and nothing happens” situation.

Approve commands as you go (the normal workflow)

Open the dashboard → Nodes → Exec approvals (target = Gateway) and:

• set the agent (main)
• keep security=allowlist
• keep ask=on-miss
• when a command comes in, click Allow once or Always allow

This will build up your allowlist over time without you hand-editing JSON.

Docs: https://docs.openclaw.ai/tools/exec-approvals

Important: don’t use exec for file writing

Even with exec working, allowlist mode doesn’t support shell redirections (>, <<). So for USER.md / IDENTITY.md / memory files, you should rely on write/edit tools (what you just enabled via profile: "coding"). Docs: https://docs.openclaw.ai/tools/exec

Optional: quick bootstrap

If you haven’t already, run once:

openclaw setup

It seeds any missing workspace files so you start from a clean baseline.

---

If this solved it, please right-click the solution message → Apps → Mark Solution so it’s indexed for the next person.

[neat pulsar]

but do you always do approvals from dashboard or can it be done in tui or telegram

[little galleon]

Not dashboard-only.

There are basically three ways to handle exec approvals:

1) Dashboard / Control UI (most common)

Control UI → Nodes → Exec approvals
You can both:

• edit policy/allowlists, and
• resolve pending prompts (Allow once / Always allow / Deny)

This works as long as you have the dashboard open on the gateway host (yours is loopback-only, so that’s usually “the Ubuntu box itself”).

2) TUI (yes)

If you’re running an operator client like the TUI (openclaw tui) on the gateway machine, it can receive the approval requests too, and you can approve them with the normal command:

• /approve <id> allow-once
• /approve <id> allow-always

• /approve <id> deny

Docs: https://docs.openclaw.ai/tools/slash-commands (see /approve)

3) Telegram (also yes) — but you must forward prompts there

Telegram won’t magically get approval prompts unless you enable forwarding. OpenClaw can forward approval requests to chat, and then you approve with the same /approve … command inside Telegram.

From the docs (example):

{
  approvals: {
    exec: {
      enabled: true,
      mode: "session" // or "targets" / "both"
    }

  }
}

Docs: https://docs.openclaw.ai/tools/exec-approvals (section “Approval forwarding to chat channels”)

• mode: "session" is usually the simplest: it sends the prompt back to the chat/session that triggered it.
• Then reply in Telegram with /approve <id> allow-once etc.

“Can I skip approvals?”

Yes, but it’s a sharp knife:

• /elevated full (or /exec … security=full …) can skip approvals for that session if you’re authorized.

If you tell me which surface you primarily use day-to-day (TUI vs Telegram), I can suggest the cleanest approvals setup (session-forwarding vs fixed targets).

[neat pulsar]

i dotn want to write ID its too difficult

[little galleon]

You don’t have to write any IDs if you don’t want to.

For exec approvals (the thing we were discussing)

If your goal is: “when the bot asks to run a command, I want to approve it from the same chat” — use session forwarding. That requires zero Telegram IDs:

{
  approvals: {
    exec: {
      enabled: true,
      mode: "session"
    }
  }
}

Then the approval prompt shows up in the same place the request happened, and you just reply: