Missing config.yaml and Openclaw reports he cant write to his own MEMORY.md | Friends of the Crustacean 🦞🤝 | Page 1

keen forge Mar 4, 2026, 4:14 AM

#

Hi folks. I've been running openclaw for ~two weeks and only just discovered I dont have a config.yaml file (simply missing from ~/.openclaw). Furthermore, my agent was remembering anything i asked it to remember. After some back and forth we came to realize the agent is writing to MEMORY.md (among other things i assume) but it doesnt persist. When I cat the MEMORY.md file nothing has changed. Anybody have a clue at to whats going on?

upbeat laurelBOT Mar 4, 2026, 4:14 AM

#

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

icy gardenBOT Mar 4, 2026, 4:16 AM

#

There isn’t a config.yaml in OpenClaw — config is JSON5.

1) Config file: where it actually lives

By default it’s here:

~/.openclaw/openclaw.json (JSON5)

You can confirm the exact path your running Gateway is using with:

openclaw config file

Docs: https://docs.openclaw.ai/help/faq#what-format-is-the-config-where-is-it

2) Memory file: it’s in the workspace, not `~/.openclaw/`

MEMORY.md lives in the agent workspace (default: ~/.openclaw/workspace), not in the state dir.

#

Check what workspace your gateway is configured to use:

openclaw config get agents.defaults.workspace

Then look for:

<workspace>/MEMORY.md (or memory.md)
<workspace>/memory/YYYY-MM-DD.md

Docs:

3) If it “writes to MEMORY.md” but nothing changes, the usual causes

One of these is almost always the culprit:

#

You’re cat’ing the file on the wrong machine (remote mode writes on the gateway host, not your laptop)
The gateway is running under a different user (common if it was started with sudo once → writes under /root/.openclaw/...)
You’re running in Docker without a persisted volume, so changes disappear when the container is recreated
The workspace path exists but is not writable by the gateway process (permissions/ownership)

Quick next step (paste output)

These 3 usually reveal it immediately:

openclaw --version
openclaw gateway status
openclaw config get agents.defaults.workspace

(If gateway status shows “Config (cli)” and “Config (service)” pointing at different configs, that’s also a big hint.)

keen forge Mar 4, 2026, 9:45 PM

#

$ openclaw --version
2026.3.2
$ openclaw gateway status
Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-03-04.log
Command: /usr/bin/node /usr/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 77636, state active, sub running, last exit 0, reason 0)
RPC probe: ok

Listening: 127.0.0.1:18789
Other gateway-like services detected (best effort):

ntth-proxy.service (user, unit: /home/avipe/.config/systemd/user/ntth-proxy.service)
Cleanup hint: systemctl --user disable --now openclaw-gateway.service
Cleanup hint: rm ~/.config/systemd/user/openclaw-gateway.service

Recommendation: run a single gateway per machine for most setups. One gateway supports multiple agents (see docs: /gateway#multiple-gateways-same-host).
If you need multiple gateways (e.g., a rescue bot on the same host), isolate ports + config/state (see docs: /gateway#multiple-gateways-same-host).
$ openclaw config get agents.defaults.workspace
/home/avipe/.openclaw/workspace

icy gardenBOT Mar 4, 2026, 9:47 PM

#

Nice — that output already tells us a lot:

You’re on 2026.3.2
Gateway is running as a user systemd service
Workspace resolves to: /home/avipe/.openclaw/workspace
Config file path is where it would be (~/.openclaw/openclaw.json), but it’s totally fine if that file doesn’t exist (defaults kick in).

Now let’s narrow down why writes to memory don’t show up on disk.

1) First: make sure you’re looking at the right memory file

In the workspace root, run:

ls -la /home/avipe/.openclaw/workspace | grep -i memory

You might have memory.md (lowercase) instead of MEMORY.md, or the bot might be writing daily notes under:

#

/home/avipe/.openclaw/workspace/memory/YYYY-MM-DD.md

2) Check if the workspace (and MEMORY.md) are actually writable

test -w /home/avipe/.openclaw/workspace && echo "workspace writable" || echo "workspace NOT writable"
ls -la /home/avipe/.openclaw/workspace/MEMORY.md /home/avipe/.openclaw/workspace/memory.md 2>/dev/null

If you see root root ownership anywhere in that workspace, that’s usually from having run OpenClaw with sudo at some point → and then the normal user service can’t update the files.

3) Quick “sentinel” test (proves whether it’s writing anywhere)

Ask your bot (in whatever chat you normally use with it):

“Please write MEMTEST-123 into memory now (MEMORY.md).”

Then immediately run:

#

grep -R "MEMTEST-123" -n /home/avipe/.openclaw/workspace 2>/dev/null

4) If it’s failing, the log usually says why (permissions / read-only)

grep -nEi "EACCES|EPERM|EROFS|permission denied|read-only|MEMORY\\.md|memory flush" /tmp/openclaw/openclaw-2026-03-04.log | tail -n 80

5) Also worth checking: are you using Docker sandboxing for the session?

If you’ve enabled sandboxing, some sessions may run in a container with a different filesystem / mount mode.

openclaw config get agents.defaults.sandbox

If you paste results from (1) and (4), we can usually point to the exact fix (it’s very often “wrong file path” or “workspace owned by root”).

keen forge Mar 4, 2026, 10:04 PM

#

$ test -w /home/avipe/.openclaw/workspace && echo "workspace writable" || echo "workspace NOT writable"
workspace writable
$ ls -la /home/avipe/.openclaw/workspace/MEMORY.md /home/avipe/.openclaw/workspace/memory.md 2>/dev/null
-rw-r--r-- 1 avipe avipe 817 Feb 24 11:13 /home/avipe/.openclaw/workspace/MEMORY.md
$ grep -R "MEMTEST-123" -n /home/avipe/.openclaw/workspace 2>/dev/null
[No output]

icy gardenBOT Mar 4, 2026, 10:06 PM

#

Cool — this rules out the “permissions / read-only filesystem” theory. Workspace is writable and the MEMORY.md file is owned by your user.

At this point the two most common explanations are:

A) You’re testing in a group / channel / thread context

Per the docs, MEMORY.md is only loaded in the main, private session — never in group contexts (to prevent public chats from poisoning your durable memory).

So if you asked it to write MEMTEST-123 from a Discord server channel/thread (or any group chat), it may intentionally not write to / use MEMORY.md, and will “forget” on purpose.

Can you confirm: did you run the MEMTEST-123 prompt in a DM with the bot (private), or in a server channel/thread?

Docs: https://docs.openclaw.ai/concepts/memory (see “MEMORY.md … only load in the main, private session”)

B) You’re looking at the wrong agent workspace

If you have more than one agent (or bindings), the chat you’re using might be routed to a different agent with a different workspace, so you’d be grepping the wrong directory.

Run:

#

openclaw agents list
openclaw agents bindings

If you see another agent/workspace, grep that workspace for MEMTEST-123.

Quick next test (should work if you do it in a DM)

DM your bot: “Write MEMTEST-123 into memory now.”
Then run:

grep -R "MEMTEST-123" -n /home/avipe/.openclaw/workspace 2>/dev/null

#

If that still shows nothing even from a DM, next step is we’ll check whether your current model/provider is actually doing tool calls (since memory writes require file tool use) — but let’s first confirm DM vs group + agent bindings.

keen forge Mar 4, 2026, 10:37 PM

#

$ openclaw agents list
Agents:

main (default)
Identity: 🧐 Majordomo (IDENTITY.md)
Workspace: ~/.openclaw/workspace
Agent dir: ~/.openclaw/agents/main/agent
Model: ntth/global.anthropic.claude-opus-4-6-v1
Routing rules: 0
Routing: default (no explicit rules)
Routing rules map channel/account/peer to an agent. Use --bindings for full rules.
Channel status reflects local config/creds. For live health: openclaw channels status --probe.
$ openclaw agents bindings
No routing bindings.

icy gardenBOT Mar 4, 2026, 10:39 PM

#

Great — that confirms there’s only one agent/workspace in play, so this isn’t a “wrong agent” issue.

At this point it’s almost certainly session context:

Key detail: `MEMORY.md` is only used in the main private session

From the docs, MEMORY.md is only loaded in the main, private session (and never in group/channel contexts). So if you’re chatting via a Discord channel/thread, webhook, or a non-main web UI session key, OpenClaw will not load that file — and your bot will “forget” even though the file exists.

Can you paste your session keys?

This will show what session(s) you’re actually chatting in:

openclaw sessions --active 10080
# or:
openclaw sessions --json

You’re looking for whether you have a session like:

#

agent:main:main ← this is the “main private session” (MEMORY.md applies)
vs things like:
agent:main:discord:... / agent:main:webchat:... / agent:main:hook:... ← MEMORY.md does not apply

What to do once we confirm

If you want durable long-term memory: chat in the main private session (agent:main:main) — e.g. DM-style usage.
If you must use a channel/thread: have it write to memory/YYYY-MM-DD.md and/or use a separate agent/workspace for that channel (so notes don’t mix).

If you paste the openclaw sessions output, I can tell you immediately which bucket you’re in and what to switch to.

keen forge Mar 4, 2026, 10:52 PM

#

I'm interacting with the agent via the webchat agent:main:main session exclusively.
$ openclaw sessions --activ
e 10080
direct agent:main:main 52m ago global.anthropic.claude-opus-4-6-v1 unknown/200k (?%) system id:fcc6a2c1-b314-49e5-a444-0eb33a7ea789
direct agent:main:cron:...3403ff 2d ago global.anthropic.claude-opus-4-6-v1 unknown/200k (?%) system id:5d428aa7-ec44-41eb-a788-df8814534fd8
direct agent:main:cron:...534fd8 2d ago global.anthropic.claude-opus-4-6-v1 unknown/200k (?%) system id:5d428aa7-ec44-41eb-a788-df8814534fd8
group agent:main:whats...6@g.us 3d ago gemini-3-flash-preview 16k/1049k (2%) system id:79d263b6-a65b-45b6-9771-2f9bacfe43bc
direct agent:main:cron:...90594f 3d ago gemini-3-flash-preview 13k/1049k (1%) system id:15415def-ccba-48c9-9f9a-12111d90594f
group agent:main:whats...8@g.us 4d ago global.anthropic.claude-opus-4-6-v1 unknown/200k (?%) id:be43c1fc-95b5-4a0c-af7f-82bc62c4c29a
direct agent:main:cron:...c88f9c 6d ago global.anthropic.claude-opus-4-6-v1 unknown/200k (?%) system id:482951a0-95dd-43fc-b835-7cce6eb9dcf5
direct agent:main:cron:...bc822a 6d ago global.anthropic.claude-opus-4-6-v1 unknown/200k (?%) system id:9c8dabce-ac4a-4a1e-a821-7a4a759ab7eb

icy gardenBOT Mar 4, 2026, 10:54 PM

#

Perfect — since you’re actually in agent:main:main, MEMORY.md should be in play. So the “group context” explanation is out.

Given everything else you’ve shown (workspace writable, no perms errors), the most likely root cause is: your tool policy doesn’t allow filesystem tools, so the agent literally can’t write/edit MEMORY.md even when it says it will.

In 2026.3.x there’s a relevant default:

tools.profile: "messaging" (common onboarding default) does NOT include group:fs, so no read/write/edit → no persistent memory writes.

1) Confirm your tool profile / allowlist

Run:

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

#

2) Fix: allow filesystem tools (minimum needed for memory persistence)

If you want the smallest change that enables memory writes:

openclaw config set tools.allow '["group:fs"]' --strict-json

(Optional but useful for recall tooling too:)

openclaw config set tools.allow '["group:fs","group:memory"]' --strict-json

If you’d rather just unrestrict everything (simplest, but broadest):

openclaw config set tools.profile "full"

#

3) Restart the gateway + re-test

openclaw gateway restart

Then ask the bot (in your webchat agent:main:main session):

“Write MEMTEST-123 to MEMORY.md now.”

And verify:

grep -n "MEMTEST-123" /home/avipe/.openclaw/workspace/MEMORY.md

If you paste the tools.profile/allow/deny outputs, I can tell you exactly which config change is the cleanest for your setup (local-only vs exposed).

tardy glen Mar 4, 2026, 10:54 PM

#

keen forge I'm interacting with the agent via the webchat agent:main:main session exclusive...

That output looks normal 👍

In OpenClaw, ALL your direct chats with an agent share one “main” session key:
agent:main:main

Your webchat is that direct agent:main:main line.
The agent:main:whats... lines are separate WhatsApp group sessions.
The agent:main:cron:... ones are background cron jobs.

Docs if you want to go deeper:
Session basics:
https://docs.openclaw.ai/concepts/session
CLI openclaw sessions:
https://docs.openclaw.ai/cli/sessions
Session tools / listing / history:
https://docs.openclaw.ai/concepts/session-tool

icy gardenBOT Mar 4, 2026, 10:54 PM

#

Yep, agreed — the session list itself looks totally normal (and since you’re in agent:main:main, MEMORY.md should be the right place).

So we’re back to: the agent likely can’t use filesystem tools (read/write/edit), which is what actually persists memory to disk.

In 2026.3.x local installs often default to tools.profile: "messaging" unless you’ve changed it — and that profile does not include group:fs, so the model can’t update MEMORY.md.

Can you paste these 3 config values?

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

If `tools.profile` is `"messaging"` (common), fix is:

Add filesystem tools to the allowed set:

#

openclaw config set tools.allow '["group:fs"]' --strict-json
openclaw gateway restart

Then re-run your test (ask it to write MEMTEST-123 to MEMORY.md and grep for it).

If you already have a tools.allow list, don’t overwrite it blindly — paste the current value and I’ll tell you the exact merged array to set.

tardy glen Mar 4, 2026, 10:56 PM

#

keen forge I'm interacting with the agent via the webchat agent:main:main session exclusive...

This is a tools‑surface issue, not sessions.

In 2026.3.x local installs often default to:
tools.profile = "messaging"
which does not include filesystem tools (group:fs), so the agent literally can’t touch MEMORY.md even though you’re in agent:main:main.

Ask OpenClaw what it’s doing:

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

If tools.profile comes back as "messaging" and you’re OK giving it file access, expand the allowlist to include filesystem tools:

openclaw config set tools.allow '["group:fs"]' --strict-json
openclaw gateway restart

Then test from webchat:
“Write a line MEMTEST-123 into MEMORY.md and tell me the filename + path you used.”

On disk, grep for it:
grep -R "MEMTEST-123" .

If they already have a non‑empty tools.allow, don’t overwrite it; paste the current JSON and we’ll build the merged array. Docs for what tools.profile, tools.allow, group:fs, etc. actually mean:
https://docs.openclaw.ai/tools
https://docs.openclaw.ai/concepts/memory

icy gardenBOT Mar 4, 2026, 10:56 PM

#

+1 to this.

One extra thing that may “click” with your original confusion: if you’ve never created ~/.openclaw/openclaw.json, you’ll have no config file at all (that’s fine — defaults apply). As soon as you run openclaw config set ..., it will create ~/.openclaw/openclaw.json for you, and then you can see/backup/edit it.

So yeah: check tools.profile/allow/deny first — if it’s the default "messaging" profile, adding group:fs is exactly what enables persistence to MEMORY.md.

keen forge Mar 4, 2026, 11:32 PM

#

running the command "openclaw config set tools.allow '["group:fs"]' --strict-json" seems to have fixed the issue. I did not even have a tools.allow declaration in my openclaw.json file (nor deny/profile for that matter). Why would it be missing altogether? Did I do something wrong during setup? Did something change with a new version? I'm worried theres other stuff missing that'll cause me a headache in the futrue

icy gardenBOT Mar 4, 2026, 11:33 PM

#

You didn’t do anything wrong — this is normal, and it is tied to newer behavior.

Why those keys were “missing”

~/.openclaw/openclaw.json is not a fully-generated config dump. It’s intentionally just an override file (a patch). Anything you don’t set is pulled from built-in defaults.

So “missing altogether” usually just means: you never overrode the default, not that setup failed.

You can always see the effective value (even if it’s not in the file) via:

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

Why it broke memory persistence specifically

In 2026.3.x, OpenClaw introduced tool “profiles”, and local onboarding/defaults commonly resolve to:

#

tools.profile = "messaging"

That profile does not include filesystem tools (group:fs), so the agent can’t read/write/edit workspace files → which includes writing to MEMORY.md.

That’s why adding:

openclaw config set tools.allow '["group:fs"]' --strict-json

immediately fixed it.

(Reference: tool profiles + groups are documented in the config reference under “Tools”: https://docs.openclaw.ai/gateway/configuration-reference )

“Am I missing other stuff that’ll bite me later?”

Probably not — but here are the two quick sanity checks I recommend:

#

openclaw config validate
openclaw models status

If those are clean, you’re in good shape. From there you generally only add config when you want to change behavior.

Glad you found the root cause. If this solved it, please mark the solution message so Answer Overflow indexes it (right‑click message → Apps → ✅ Mark Solution).

#Missing config.yaml and Openclaw reports he cant write to his own MEMORY.md