import Backup .md files | Friends of the Crustacean 🦞🤝 | Page 1

solid parrot Apr 21, 2026, 4:41 AM

#

I have backed up the 7 .md files(SOUL.md, AGENTS.md etc) from my previous OpenClaw before I deleted it. I now want my newly set up OpenClaw to inherit these .md files. What is the best way to do it?

pulsar yarrowBOT Apr 21, 2026, 4:41 AM

#

forest folioBOT Apr 21, 2026, 4:41 AM

#

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

pulsar yarrowBOT Apr 21, 2026, 4:41 AM

#

ocean gulchBOT Apr 21, 2026, 4:44 AM

#

Best way is to restore them into the agent workspace, not the repo root.

Default workspace: ~/.openclaw/workspace
If you changed it, check agents.defaults.workspace in ~/.openclaw/openclaw.json or run openclaw status
Copy your backed-up AGENTS.md, SOUL.md, TOOLS.md, IDENTITY.md, USER.md, HEARTBEAT.md, and MEMORY.md/memory.md into that workspace, replacing the starter copies
Then run openclaw setup --workspace ~/.openclaw/workspace to recreate anything missing without overwriting existing files
Restart the gateway after that

A couple gotchas:

BOOTSTRAP.md is one-time only, so you usually do not need to restore it if the new workspace already bootstrapped
If your old file is lowercase memory.md, that is a legacy fallback. Prefer MEMORY.md, and do not keep both
If your Gateway runs remotely, copy the files to the gateway host’s workspace, not your local laptop

If you want the full old brain back, not just the .md files, also copy the old ~/.openclaw state dir and then run openclaw doctor.

Docs:

#

If you want, I can give you the exact copy commands for Linux/macOS or Windows.

solid parrot Apr 21, 2026, 4:50 AM

#

The new OpenClaw is on a VPS running Linux Ubuntu 24.04

ocean gulchBOT Apr 21, 2026, 4:51 AM

#

Yep, then the important bit is: copy them onto the VPS, into the VPS’s active workspace.

If you are using the default workspace, the path is:

~/.openclaw/workspace

Easiest Linux VPS flow

From your local machine, copy the files up with scp:

scp AGENTS.md SOUL.md TOOLS.md IDENTITY.md USER.md HEARTBEAT.md MEMORY.md youruser@your-vps:~/.openclaw/workspace/

If your old backup has legacy lowercase memory.md, use:

#

scp memory.md youruser@your-vps:~/.openclaw/workspace/MEMORY.md

Then SSH into the VPS and run:

openclaw setup --workspace ~/.openclaw/workspace
openclaw gateway restart
openclaw status

Notes

You usually do not want to restore BOOTSTRAP.md
Do not keep both memory.md and MEMORY.md, prefer MEMORY.md
If your workspace path is custom, check agents.defaults.workspace in ~/.openclaw/openclaw.json first

#

If you want the full previous setup back, not just personality/memory files, then also restore the old ~/.openclaw state directory and run openclaw doctor.

Docs:

If you want, I can give you the exact scp command once you tell me:

where the backup files are now, and
the VPS username/IP.

solid parrot Apr 21, 2026, 5:33 AM

#

Another issue. When I run OpenClaw status, I see this critical issue:

Security audit
Summary: 1 critical · 0 warn · 1 info
CRITICAL Discord security warning
Discord guilds: groupPolicy="open" with no guild/channel allowlist; any channel can trigger (mention-gated). Set channels.discord.groupPolicy="allowlist" and c…

However, when I run OpenClaw security audit, that same security issue is not there:

OpenClaw security audit
Summary: 0 critical · 1 warn · 1 info
Run deeper: openclaw security audit --deep

WARN
security.trust_model.multi_user_heuristic Potential multi-user setup detected (personal-assistant model warning)
Heuristic signals indicate this gateway may be reachable by multiple users:

channels.telegram.groupPolicy="allowlist" with configured group targets
No unguarded runtime/process tools were detected by this heuristic.
No unguarded runtime/filesystem contexts detected.
OpenClaw's default security model is personal-assistant (one trusted operator boundary), not hostile multi-tenant isolation on one shared gateway.
Fix: If users may be mutually untrusted, split trust boundaries (separate gateways + credentials, ideally separate OS users/hosts). If you intentionally run shared-user access, set agents.defaults.sandbox.mode="all", keep tools.fs.workspaceOnly=true, deny runtime/fs/web tools unless required, and keep personal/private identities + credentials off that runtime.

ocean gulchBOT Apr 21, 2026, 5:35 AM

#

That mismatch is not what I’d expect. openclaw status and openclaw security audit should usually agree on a finding like that.

My first question is:

openclaw --version

After that, please run these on the VPS and paste the output:

openclaw gateway status
openclaw status --all
openclaw security audit --deep

Most likely causes are:

#

the Gateway service is running with an older or different config than the file your shell is auditing
your Discord config is coming from an include/account override the plain audit is not surfacing the same way
you hit a version-specific reporting bug

A few notes:

openclaw security audit --deep is the better tie-breaker here, because it adds the live Gateway probe
openclaw gateway status can show which config/path the service is actually using
please redact tokens/passwords before pasting anything

If you want the likely fix in parallel, the status warning is basically saying your Discord side still looks too open somewhere, usually:

channels: {
  discord: {
    groupPolicy: "allowlist",

#

    // plus guild/channel allowlists
  }
}

Docs:

Paste those 3 outputs plus openclaw --version, and I’ll help narrow it down fast.

solid parrot Apr 21, 2026, 5:43 AM

#

openclaw-agent@automation:~$ openclaw --version
OpenClaw 2026.4.15 (041266a)

Which part do you need to see exactly from these two(openclaw gateway status
openclaw status --all)? There are some sensitive information which I don't think I should paste here.

ocean gulchBOT Apr 21, 2026, 5:44 AM

#

Yep, do not paste secrets here.

2026.4.15 is recent enough, so I’m less worried about an old-release bug and more about config/path drift.

What I need is only the safe bits:

From `openclaw gateway status`

Please paste only the lines that mention:

config path / “using config”
probe target URL
whether the gateway/RPC is reachable

From `openclaw status --all`

Please paste only:

the Security audit section

#

the Discord part of the Channels section

Optional but useful

If you can, also run:

openclaw security audit --deep

and paste just the Discord-related finding(s) from that output.

You can freely redact:

tokens
passwords
session IDs
usernames/hostnames if you want

#

What I’m trying to confirm is basically:

is the Gateway service reading the same config file your shell is auditing, and
does the Discord config still have groupPolicy: "open" somewhere, maybe in an account override or included file.

If you want, you can also paste a sanitized channels.discord config block with the token removed, and that might be enough on its own.

solid parrot Apr 21, 2026, 5:48 AM

#

openclaw gateway status

Service config looks out of date or non-standard.
Service config issue: Gateway service PATH includes version managers or package managers; recommend a minimal PATH. (/home/openclaw-agent/.nvm/versions/node/v24.15.0/bin)
Service config issue: Gateway service uses Node from a version manager; it can break after upgrades. (/home/openclaw-agent/.nvm/versions/node/v24.15.0/bin/node)
Service config issue: System Node 22 LTS (22.14+) or Node 24 not found; install it before migrating away from version managers.
Recommendation: run "openclaw doctor" (or "openclaw doctor --repair").
Config (cli): ~/.openclaw/openclaw.json
Config (service): ~/.openclaw/openclaw.json

Probe target: ws://127.0.0.1:18789

Runtime: unknown (systemctl --user unavailable: Failed to connect to bus: Permission denied
Failed to read server status: Transport endpoint is not connected)
RPC probe: ok

#

OpenClaw status --all

Discord accounts
┌──────────┬──────────┬───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Account │ Status │ Notes │
├──────────┼──────────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ default │ OK │ token:config

OpenClaw security audit --deep
Summary: 0 critical · 1 warn · 1 info
Run deeper: openclaw security audit --deep

WARN
security.trust_model.multi_user_heuristic Potential multi-user setup detected (personal-assistant model warning)
Heuristic signals indicate this gateway may be reachable by multiple users:

channels.telegram.groupPolicy="allowlist" with configured group targets
No unguarded runtime/process tools were detected by this heuristic.
No unguarded runtime/filesystem contexts detected.
OpenClaw's default security model is personal-assistant (one trusted operator boundary), not hostile multi-tenant isolation on one shared gateway.
Fix: If users may be mutually untrusted, split trust boundaries (separate gateways + credentials, ideally separate OS users/hosts). If you intentionally run shared-user access, set agents.defaults.sandbox.mode="all", keep tools.fs.workspaceOnly=true, deny runtime/fs/web tools unless required, and keep personal/private identities + credentials off that runtime.

INFO
summary.attack_surface Attack surface summary
groups: open=0, allowlist=2
tools.elevated: enabled
hooks.webhooks: disabled
hooks.internal: enabled
browser control: enabled
trust model: personal assistant (one trusted operator boundary), not hostile multi-tenant on one shared gateway

ocean gulchBOT Apr 21, 2026, 5:49 AM

#

That helps a lot.

The key bit is:

Config (cli) and Config (service) are both ~/.openclaw/openclaw.json

So this does not look like “CLI and service are reading different config files”. Good, we can rule that out.

Also:

the nvm / PATH warnings are real, but they are probably separate from your Discord policy mismatch
RPC probe: ok is the important part here

What I need next

The fastest next step is a sanitized channels.discord block from ~/.openclaw/openclaw.json.

#

Please paste just that block with the token removed, especially these fields if present:

groupPolicy
accounts
guilds
channels
allowFrom
any $include related to Discord

I’m specifically looking for one of these:

channels.discord.groupPolicy: "open" at the top level
channels.discord.accounts.<something>.groupPolicy: "open" in an account override
a Discord block that has groupPolicy: "open" but no real guild/channel allowlist

If you’d rather not paste config, then paste only the Discord-related part of:

#

openclaw status --all

or

openclaw security audit --deep

with secrets redacted.

So at this point I do not need the whole status output, just the Discord config/finding.

#

Nice, this is actually pretty clear now.

Your deep audit says:

groups: open=0, allowlist=2

So the active config it can see does not currently have any open group policy, including Discord. That means the earlier openclaw status critical is probably not a real live security problem right now.

My read

openclaw security audit --deep is the better tie-breaker here
based on that output, your Discord config looks allowlisted, not open
if plain openclaw status still shows the Discord critical on a fresh run, I think you’ve hit a status reporting inconsistency/bug

What I’d do

Re-run plain:

#

openclaw status

If it still shows:

Discord guilds: groupPolicy="open" ...

then I would trust openclaw security audit --deep more for the actual security state.

If the mismatch keeps happening, that is worth filing as a bug:
https://github.com/openclaw/openclaw/issues

Separate issue

The earlier nvm / PATH warning from openclaw gateway status is still worth fixing later, but that looks like a different problem.

#

If you want, paste just the Security audit block from plain openclaw status after a fresh run, and I can help confirm whether it is just a reporting bug.

solid parrot Apr 21, 2026, 5:55 AM

#

{
"enabled": true,
"token": "<REDACTED>",
"allowFrom": [
"723<REDACTED>8456"
]
}

ocean gulchBOT Apr 21, 2026, 5:56 AM

#

Yep, that Discord block looks fine.

The important part is that your deep audit already says:

groups: open=0
allowlist=2

So in the resolved live config, Discord is not being treated as groupPolicy: "open".

A couple of useful takeaways:

your posted Discord block does not show any open guild policy
allowFrom is not the problem here
this lines up with the deep audit, which is the stronger check

So at this point, I’d treat the earlier plain openclaw status Discord critical as most likely:

#

a stale earlier read, or
a status reporting bug/inconsistency

My recommendation

trust openclaw security audit --deep for the actual security state here
if plain openclaw status still keeps showing that Discord critical on a fresh run, file it as a bug with:
- openclaw --version
- the plain openclaw status security block
- the openclaw security audit --deep output
- the sanitized Discord block you pasted here

Bug tracker: https://github.com/openclaw/openclaw/issues

So, good news: I do not think your Discord config is actually open right now. 🎉

Glad that helped! 🎉

#

If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution.
This helps Answer Overflow index the solution for future users.

solid parrot Apr 21, 2026, 6:00 AM

#

is there an env var or config flag to skip the npm registry update check in openclaw status?

ocean gulchBOT Apr 21, 2026, 6:01 AM

#

I don’t see a documented env var or config flag for that, no.

What I could verify:

openclaw status currently hardcodes the update probe with includeRegistry: true
update.checkOnStart: false only disables the gateway startup update hint, not the openclaw status registry check

So for now:

No known env var/config toggle to skip the npm registry check in openclaw status
If you want a status-ish check without that path, use openclaw gateway status or openclaw health
If this matters for offline / locked-down VPS setups, it’s worth a feature request: https://github.com/openclaw/openclaw/issues

Docs:

#

Glad that helped! 🎉
If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution.
This helps Answer Overflow index the solution for future users.

solid parrot Apr 21, 2026, 6:05 AM

#

what about the earlier nvm / PATH warning from openclaw gateway status?

ocean gulchBOT Apr 21, 2026, 6:06 AM

#

That warning means your gateway service is pointing at Node inside ~/.nvm/..., not a system Node.

That can work, but it is fragile:

nvm paths can change after upgrades
services do not load your shell init the way an interactive shell does
after a reboot/update, the service can suddenly stop finding the same Node binary

So the warning is basically: “this works now, but it may break later.”

Best fix on Ubuntu

Install a system Node, then let OpenClaw rewrite the service:

curl -fsSL https://deb.nodesource.com/setup_24.x | sudo -E bash -

#

sudo apt-get install -y nodejs
openclaw doctor --repair

If it still keeps the old service wiring, force-refresh it:

openclaw gateway install --force
openclaw gateway restart
openclaw gateway status

Important nuance

If you are running OpenClaw manually in your shell, nvm is much less of a problem.

#import Backup .md files

Easiest Linux VPS flow

Notes

From openclaw gateway status

From openclaw status --all

Optional but useful

What I need next

My read

What I’d do

Separate issue

My recommendation

Best fix on Ubuntu

Important nuance

From `openclaw gateway status`

From `openclaw status --all`