bootstrap files | Friends of the Crustacean 🦞🤝 | Page 1

peak wren Apr 14, 2026, 4:13 AM

#

why do I see
│ Agents │ 1 · no bootstrap files · sessions 21 · default main active 16m ago

does that mean my AGENTS.md, MEMORY.md and SOUL.md are not being read? that would explain a lot 🙂

gaunt rainBOT Apr 14, 2026, 4:13 AM

#

raw lanternBOT Apr 14, 2026, 4:13 AM

#

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

thin riverBOT Apr 14, 2026, 4:14 AM

#

Nope, that status line is a bit misleading 🙂

no bootstrap files means no BOOTSTRAP.md is currently present. It does not mean AGENTS.md / SOUL.md are being ignored.

I checked the docs and source:

the status line is literally based on whether BOOTSTRAP.md exists
AGENTS.md, SOUL.md, TOOLS.md, IDENTITY.md, USER.md, and HEARTBEAT.md are still injected into Project Context on normal turns
MEMORY.md is the gotcha: in Discord guild channels, it does not auto-load by default. That part absolutely could explain “that would explain a lot” 😅

So in your case:

AGENTS.md: yes, should be read
SOUL.md: yes, should be read
MEMORY.md: not automatically in Discord channels, usually only in DMs unless you explicitly pull memory or move durable rules into AGENTS.md / USER.md

Docs:

#

workspace/bootstrap behavior: https://docs.openclaw.ai/concepts/system-prompt
workspace files location: https://docs.openclaw.ai/help/faq
Discord memory behavior: https://docs.openclaw.ai/channels/discord

If you want, send your openclaw --version plus whether this is happening in a guild channel vs DM, and I can help narrow down why it still feels like AGENTS.md/SOUL.md aren’t sticking.

peak wren Apr 14, 2026, 4:16 AM

#

give me the commands to fix these errors
https://gist.github.com/viklall/cc17e4ef371d74fa84c699caa76535ed

thin riverBOT Apr 14, 2026, 4:17 AM

#

I’m pulling the actual audit output so I can give you the right commands, not generic ones. Also, please include openclaw --version with the result, because a few security-audit keys changed across releases.

thin riverBOT Apr 14, 2026, 4:17 AM

#

peak wren give me the commands to fix these errors https://gist.github.com/viklall/cc17e4e...

I pulled the gist. It’s truncated, but for the findings that are visible, these are the commands I’d use. Replace the placeholders with your real Telegram user/group IDs. For the findings visible in that gist, I’d do this first:

openclaw --version
openclaw security audit --fix
openclaw config set gateway.controlUi.allowInsecureAuth false --strict-json
openclaw config set gateway.auth.rateLimit '{"maxAttempts":10,"windowMs":60000,"lockoutMs":300000}' --strict-json
openclaw config set tools.fs.workspaceOnly true --strict-json
openclaw gateway restart
openclaw security audit --deep

Then fix Telegram properly, with explicit allowlists:

openclaw config set channels.telegram.groupPolicy allowlist

#

openclaw config set channels.telegram.allowFrom '["123456789"]' --strict-json
openclaw config set channels.telegram.groups '{"-1001234567890":{"requireMention":true}}' --strict-json
openclaw gateway restart

If you want multiple Telegram groups:

openclaw config set channels.telegram.groups '{"-1001234567890":{"requireMention":true},"-1009876543210":{"requireMention":true}}' --strict-json
openclaw gateway restart

If you also want sandboxing for group/channel sessions, and Docker sandboxing is already working, add this too:

#

openclaw config set agents.defaults.sandbox.mode non-main
openclaw gateway restart

If this bot should never use file/exec tools at all, go even tighter:

openclaw config set tools.profile messaging
openclaw gateway restart

A couple of important notes:

123456789 must be your numeric Telegram user ID
-1001234567890 must be the Telegram group/supergroup chat ID
don’t put group IDs in groupAllowFrom

#

The gist only shows the first few findings, so if you want the exact commands for the remaining +3 more, paste:

openclaw security audit --deep

Docs:

If you paste openclaw --version and the full openclaw security audit --deep, I can turn it into a tighter copy/paste set for your exact config.

peak wren Apr 14, 2026, 4:19 AM

#

i ran this so far

openclaw --version
openclaw security audit --fix
openclaw config set gateway.controlUi.allowInsecureAuth false --strict-json
openclaw config set gateway.auth.rateLimit '{"maxAttempts":10,"windowMs":60000,"lockoutMs":300000}' --strict-json
openclaw config set tools.fs.workspaceOnly true --strict-json
openclaw gateway restart
openclaw security audit --deep

i dont need anyone else from telegram individuals or groups to message

thin riverBOT Apr 14, 2026, 4:20 AM

#

Nice, then I’d lock Telegram down hard.

If you want only your own Telegram DM to work, and no groups at all:

openclaw config set channels.telegram.groupPolicy disabled
openclaw config set channels.telegram.dmPolicy allowlist
openclaw config set channels.telegram.allowFrom '["YOUR_NUMERIC_TELEGRAM_USER_ID"]' --strict-json
openclaw gateway restart
openclaw security audit --deep

If you want Telegram completely disabled for inbound messages, including your own DMs:

openclaw config set channels.telegram.groupPolicy disabled

#

openclaw config set channels.telegram.dmPolicy disabled
openclaw gateway restart
openclaw security audit --deep

I’d also clear any leftover group config if you had old Telegram groups configured:

openclaw config set channels.telegram.groups '{}' --strict-json
openclaw gateway restart

So the usual secure setup for a personal bot is:

dmPolicy: allowlist
allowFrom: [your numeric Telegram user id]

#

groupPolicy: disabled

That should wipe out the “any Telegram group can add + ping” class of warnings.

Docs: https://docs.openclaw.ai/channels/telegram

If you want, paste the new openclaw security audit --deep output and I’ll sanity-check what’s left.

peak wren Apr 14, 2026, 4:20 AM

#

https://gist.github.com/viklall/cc17e4ef371d74fa84c699caa76535ed

thin riverBOT Apr 14, 2026, 4:21 AM

#

That gist still looks like the old audit output.

It still shows:

channels.telegram.groupPolicy="open"
gateway.controlUi.allowInsecureAuth=true

So one of these is true:

the gist wasn’t updated,
the gateway restarted against a different config file,
one of the config set commands didn’t land where you expected.

If you don’t need Telegram at all, the cleanest fix is just:

#

openclaw config set channels.telegram.enabled false --strict-json
openclaw gateway restart
openclaw security audit --deep

If you do want only your own Telegram DM, use this instead:

openclaw config set channels.telegram.groupPolicy disabled
openclaw config set channels.telegram.dmPolicy allowlist
openclaw config set channels.telegram.allowFrom '["YOUR_NUMERIC_TELEGRAM_USER_ID"]' --strict-json
openclaw gateway restart
openclaw security audit --deep

Before you re-gist it, I’d verify the live config with:

#

openclaw config get channels.telegram.enabled --json
openclaw config get channels.telegram.groupPolicy --json
openclaw config get channels.telegram.dmPolicy --json
openclaw config get channels.telegram.allowFrom --json
openclaw config get gateway.controlUi.allowInsecureAuth --json
openclaw config get gateway.auth.rateLimit --json
openclaw gateway status

Paste that output, or paste the new openclaw security audit --deep directly here. I’m pretty sure the current gist is just stale.

peak wren Apr 14, 2026, 4:24 AM

#

how do i find my numberic telegram id

thin riverBOT Apr 14, 2026, 4:24 AM

#

Easiest ways:

Private, no third-party bot

DM your Telegram bot
Run:
```
openclaw logs --follow
```
Look for from.id in the Telegram event, that numeric value is your user ID

Official Telegram API

curl "https://api.telegram.org/bot<YOUR_BOT_TOKEN>/getUpdates"

Then find your message and read message.from.id.

#

Quick but less private

DM @userinfobot
or DM @getidsbot

Once you have it, lock Telegram DM to just you with:

openclaw config set channels.telegram.dmPolicy allowlist
openclaw config set channels.telegram.allowFrom '["YOUR_NUMERIC_ID"]' --strict-json
openclaw config set channels.telegram.groupPolicy disabled
openclaw gateway restart

Docs: https://docs.openclaw.ai/channels/telegram

If you want, paste the getUpdates JSON or the relevant log snippet and I’ll point at the exact number.

peak wren Apr 14, 2026, 4:26 AM

#

iklall@vixclaw8-v3:~/.openclaw/workspace$ openclaw config get channels.telegram.enabled --json
openclaw config get channels.telegram.groupPolicy --json
openclaw config get channels.telegram.dmPolicy --json
openclaw config get channels.telegram.allowFrom --json
openclaw config get gateway.controlUi.allowInsecureAuth --json
openclaw config get gateway.auth.rateLimit --json
openclaw gateway status
true
"disabled"
"allowlist"
[
"473602828"
]
false
{
"maxAttempts": 10,
"windowMs": 60000,
"lockoutMs": 300000
}

🦞 OpenClaw 2026.4.12 (1c0672b) — Half butler, half debugger, full crustacean.

│
◇
Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-04-13.log
Command: /usr/bin/node /home/viklall/.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=lan (0.0.0.0), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://10.128.0.10:18789/
Probe note: bind=lan listens on 0.0.0.0 (all interfaces); probing via 127.0.0.1.

Runtime: running (pid 26700, state active, sub running, last exit 0, reason 0)
RPC probe: ok

Listening: 0.0.0.0:18789
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting
viklall@vixclaw8-v3:~/.openclaw/workspace$

thin riverBOT Apr 14, 2026, 4:26 AM

#

Yep, this looks materially fixed now. Nice catch.

What your live config says now:

Telegram groups: disabled
Telegram DMs: allowlist
Allowed Telegram sender: just your ID (473602828)
Control UI insecure auth: off
Gateway auth rate limiting: on

So the old gist is almost certainly just stale. Your current config no longer matches those old Telegram/auth warnings.

The one thing I’d still think about is this:

bind=lan
Listening: 0.0.0.0:18789

#

That means the gateway is exposed on the network. If you do not need remote access, harden it further with:

openclaw config set gateway.bind loopback
openclaw gateway restart

If you do need remote access, then keeping lan can be fine, but I’d want:

auth enabled
rate limiting enabled, which you now have
ideally HTTPS / Tailscale instead of plain LAN exposure

So my read is:

Telegram side looks good now
the gist is outdated
remaining risk is mostly network exposure from bind=lan

#

I’d rerun and paste fresh output directly instead of the old gist:

openclaw security audit --deep
openclaw status --all

If you paste that, I can tell you exactly what’s left, if anything.

Glad we caught this 🙂
If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it.

peak wren Apr 14, 2026, 4:27 AM

#

https://gist.github.com/viklall/cc17e4ef371d74fa84c699caa76535ed

thin riverBOT Apr 14, 2026, 4:28 AM

#

Much better. You knocked out the Telegram/auth problems.

What’s left now:

The real remaining criticals

They’re both from installed skills, not core OpenClaw config:

openclaw-github-assistant-2-0-1
newsapi-search

The audit is flagging possible env harvesting patterns, which I’d treat seriously unless you personally reviewed that code and trust it.

Safest immediate fix, move them out of the workspace skill path:

mkdir -p ~/.openclaw/disabled-skills

#

mv ~/.openclaw/workspace/skills/openclaw-github-assistant-2-0-1 ~/.openclaw/disabled-skills/
mv ~/.openclaw/workspace/skills/newsapi-search ~/.openclaw/disabled-skills/
openclaw gateway restart
openclaw security audit --deep

That should clear the 2 critical findings.

Remaining warnings

tools.exec.strictInlineEval
Good hardening, worth enabling:

openclaw config set tools.exec.strictInlineEval true --strict-json
openclaw gateway restart

#

gateway.nodes.denyCommands ineffective entries
This is a config cleanup warning, not an immediate compromise. It means some entries in your deny list are bogus command names.

To inspect it:
```
openclaw config get gateway.nodes.denyCommands --json
```
Paste that if you want, and I’ll tell you exactly which entries to keep/remove.
security.trust_model.multi_user_heuristic
This is basically OpenClaw saying: “you exposed runtime/file tools in a shared-ish environment.”

If this gateway is really just for you, this warning is more of a posture warning than a bug.

If you want to harden it more, and Docker sandboxing is available:

#

   openclaw config set agents.defaults.sandbox.mode non-main
   openclaw gateway restart

That’s a nice compromise because channel/group sessions get sandboxed.

Also, your original bootstrap question

This confirms it too:

Bootstrap file: ABSENT is normal
it means no BOOTSTRAP.md
it does not mean AGENTS.md / SOUL.md are ignored

So the status confusion was real, but the bigger issue turned out to be security posture + those third-party skills.

Docs:

#

If you paste openclaw config get gateway.nodes.denyCommands --json, I can finish the cleanup.

peak wren Apr 14, 2026, 4:30 AM

#

https://gist.github.com/viklall/cc17e4ef371d74fa84c699caa76535ed

thin riverBOT Apr 14, 2026, 4:31 AM

#

I rechecked it, same result. The Telegram/auth stuff is fixed. What remains is mostly this:

Fix now

These are the only remaining criticals:

openclaw-github-assistant-2-0-1
newsapi-search

They’re third-party skills flagged for possible env harvesting. If you don’t fully trust them, move them out of the skill path:

mkdir -p ~/.openclaw/disabled-skills
mv ~/.openclaw/workspace/skills/openclaw-github-assistant-2-0-1 ~/.openclaw/disabled-skills/
mv ~/.openclaw/workspace/skills/newsapi-search ~/.openclaw/disabled-skills/
openclaw gateway restart
openclaw security audit --deep

#

Good hardening, low risk

openclaw config set tools.exec.strictInlineEval true --strict-json
openclaw gateway restart

Optional hardening

If this gateway is reachable from shared Discord channels and you want better isolation, and Docker sandboxing is available:

openclaw config set agents.defaults.sandbox.mode non-main
openclaw gateway restart

Things you can mostly ignore for the moment

Port 18789 is already in use in status --all just means your gateway is already running
Bootstrap file ABSENT is still normal

#

gateway.nodes.denyCommands warning is config cleanup, not your biggest problem right now, especially since node service isn’t even installed

So the next meaningful move is really just: quarantine those 2 skills.

If you do that and paste the next audit, we should be down to warnings-only.

peak wren Apr 14, 2026, 4:32 AM

#

WARN Some gateway.nodes.denyCommands entries are ineffective

thin riverBOT Apr 14, 2026, 4:32 AM

#

That warning means your gateway.nodes.denyCommands list contains names OpenClaw does not actually match, so those entries are doing nothing.

In your audit, the bad entries were:

camera.snap
camera.clip
screen.record
contacts.add
calendar.add
reminders.add
sms.send

denyCommands only matches exact node command IDs, not shell text or guessed names.

So the fix is:

inspect the current list

#

   openclaw config get gateway.nodes.denyCommands --json

remove the bogus entries, or replace them with real command IDs

If you want, paste that JSON and I’ll give you the exact cleaned replacement list.

Also, since your node service isn’t installed, this warning is more config hygiene than an active problem right now.

#bootstrap files

The real remaining criticals

Remaining warnings

Also, your original bootstrap question

Fix now

Good hardening, low risk

Optional hardening

Things you can mostly ignore for the moment