OpenClaw not bootstrapping

[zinc mauve]

Hey guys. I tried to do a fresh install of openclaw on a clean Ubuntu LTS machine, node 24 LTS.

agent reacted as follows:

◇  How do you want to hatch your agent?
│  Hatch in Terminal (recommended)

🦞 OpenClaw 2026.5.12 (f066dd2) — I don't just autocomplete—I auto-commit (emotionally), then ask you to review (logically).

 openclaw tui - local embedded - agent main - session main

 session agent:main:main

✅ Session reset.

🦞 OpenClaw 2026.5.12 (f066dd2)
⏱️ Uptime: gateway 6m 9s · system 1h
🧠 Model: ollama/gemma4:latest · 🔑 api-key (ollama:default)
📚 Context: 0/131k (0%) · 🧹 Compactions: 0
🧵 Session: agent:main:main • updated just now
⚙️ Execution: direct · Runtime: OpenClaw Pi Default · Think: medium
🪢 Queue: steer (depth 0)


Wake up, my friend!


Good morning! I hope you're having a wonderful day so far. How can I help you today? 😊
 local ready | idle
 agent main | session main | ollama/gemma4:latest | think medium | tokens ?/131k
────────────────────────────────────────────────────────────────────────────────────────────────

BOOTSTRAP.md is default (ask about name/identity/emoji....)
Same on 2026.5.14-beta.2

[hidden bronze]

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

[molten viper]

This looks like the bootstrap run is not being followed by the selected model, not a normal successful hatch.

I checked the current source/docs: a brand-new workspace is expected to stay “bootstrap pending” while BOOTSTRAP.md exists. The first visible reply is explicitly supposed to read/follow BOOTSTRAP.md, and setup is considered complete only after that file is deleted after identity/user setup. So a generic “Good morning, how can I help?” while default BOOTSTRAP.md still exists is suspicious.

The fastest useful triage:

openclaw --version
openclaw status --all
openclaw models status
openclaw logs --follow

Given your status shows ollama/gemma4:latest, I’d also test once with a stronger/cloud model if you can. Local Ollama models are supported, but the docs specifically warn that agents using tools/context injection need large capable models, and weaker local models may ignore injected instructions like this. Docs: https://docs.openclaw.ai/help/faq and https://docs.openclaw.ai/concepts/models

If it still ignores BOOTSTRAP.md on a stronger model, that’s likely worth filing as a bug with the four command outputs above plus the unchanged BOOTSTRAP.md: https://github.com/openclaw/openclaw/issues

[zinc mauve]

I have to break this down due to the length limit:

elisabeth@agent-dev:~/.openclaw$ openclaw --version
OpenClaw 2026.5.14-beta.2 (e029c12)

(also same result with the 'release')

[molten viper]

Thanks, version noted: 2026.5.14-beta.2 (e029c12), and same behavior on stable.

Please keep sending the chunks. The most useful next ones are:

openclaw status --all
openclaw models status

And if you can, a short log slice around the first hatch:

openclaw logs --follow

You can stop it after the agent gives the generic greeting. I’m mainly looking for whether the bootstrap context was injected, whether the run is marked full vs lightweight, and whether Ollama/model transport logged anything odd.

[zinc mauve]

elisabeth@agent-dev:~/.openclaw$ openclaw models status

🦞 OpenClaw 2026.5.14-beta.2 (e029c12) — Gateway online—please keep hands, feet, and appendages inside the shell at all times.

Config        : ~/.openclaw/openclaw.json
Agent dir     : ~/.openclaw/agents/main/agent
Default       : ollama/gemma4:latest
Fallbacks (0) : -
Image model   : -
Image fallbacks (0): -
Aliases (0)   : -
Configured models (0): all

Auth overview
Auth store    : ~/.openclaw/agents/main/agent/auth-profiles.json
Shell env     : off
Providers w/ OAuth/tokens (0): -
- ollama effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | ollama:default=marker(ollama-local) | models.json=OL...EY | source=models.json: ~/.openclaw/agents/main/agent/models.json | synthetic=plugin-owned | source=models.providers.ollama (synthetic local key)

OAuth/token status
- none

for the status --all I need to get creative - discord length limits...

[molten viper]

That confirms the run is only using local Ollama, with no cloud fallback configured. That makes “model ignored bootstrap instructions” the leading suspect, especially since the system expected BOOTSTRAP.md to drive the first reply.

For status --all, easiest options:

• attach it as a .txt file here, or
• paste only these sections first: gateway/session/agent status, model/runtime section, and the log tail/errors.

You can capture it with:

openclaw status --all > openclaw-status.txt

One useful isolation test, if you have any cloud provider configured or can temporarily configure one: switch the default model away from Ollama, reset the session, and hatch again. If bootstrap works there, this is almost certainly Ollama/gemma4 instruction-following rather than workspace state.

Docs for the model side: https://docs.openclaw.ai/concepts/models

[zinc mauve]

I cannot drop it in so here goes the 'manual stripped'

• Version: 2026.5.14-beta.2
• OS: linux 7.0.0-15-generic (x64)
• Node: 24.15.0
• config: ~/.openclaw/openclaw.json
• dashboard: http://127.0.0.1:18789/
• tailscale: off
• channel: beta (before stable, same result)
• update: pnpm - up to date · npm beta 2026.5.14-beta.2
• Gateway: local · ws://127.0.0.1:18789 (local loopback) · reachable 65ms · auth token
• Security: Run: openclaw security audit --deep
• Gateway self : unknownenabled · running (pid 17796, state active)
• Node service: systemd user not installed - Agents: 1 total · 1 bootstrapping · 0 active · 1 sessions
• Secrets: none

Channels: none
Agents:

• main, bootstrap.md present, sessions 1, Active: 21m ago, ~/.openclaw/agents/main/sessions/sessions.json is the store

Diagnosis (read-only)

Gateway connection details:
  Gateway target: ws://127.0.0.1:18789
  Source: local loopback
  Config: /home/elisabeth/.openclaw/openclaw.json
  Bind: loopback

✓ Config: /home/elisabeth/.openclaw/openclaw.json
✓ Secret diagnostics (0)
✓ Restart sentinel: none
✓ Port 18789
  Detected OpenClaw Gateway listener on the configured port.
! Tailscale exposure: off · daemon unknown
✓ Skills: 9 eligible · 0 missing · /home/elisabeth/.openclaw/workspace
✓ Plugin compatibility (none)
✓ Channel issues (none)

Pasteable debug report. Auth tokens redacted.
Troubleshooting: https://docs.openclaw.ai/troubleshooting

◇

[molten viper]

This status is internally consistent: Gateway is reachable, no channel/plugin issue, and the agent is still marked bootstrapping because BOOTSTRAP.md is still present. Node 24 is probably not the interesting part here.

At this point I’d split it into two checks:

1. Did OpenClaw inject the bootstrap instruction?
2. Did ollama/gemma4:latest ignore it?

For check 1, please grab the log lines from a fresh reset/hatch:

openclaw logs --follow

Then in another terminal do the hatch/reset that triggers the generic greeting, stop logs after the reply, and paste the relevant slice. I’m looking for bootstrap/context/session warnings, not tokens.

For check 2, if you want a quick workaround/test, manually tell the agent:

[molten viper]

Read BOOTSTRAP.md and follow it before replying normally.

If it follows that explicit message but not the injected first-run prefix, that points to injection/ordering. If it still gives generic chat, that points harder at the local model.

Also: if this stays reproducible on stable + beta with the same clean install, I’d file it after the log slice. The key bug signal is: status says 1 bootstrapping, BOOTSTRAP.md present, but first reply ignores bootstrap.

[zinc mauve]

12:42:02+00:00 info gateway {"subsystem":"gateway"} loading configuration…
12:42:02+00:00 info gateway {"subsystem":"gateway"} resolving authentication…
12:42:02+00:00 info gateway {"subsystem":"gateway"} starting...
12:42:05+00:00 info gateway {"subsystem":"gateway"} starting HTTP server...
12:42:05+00:00 info gateway/health-monitor {"subsystem":"gateway/health-monitor"} started (interval: 300s, startup-grace: 60s, channel-connect-grace: 120s)
12:42:05+00:00 info gateway {"subsystem":"gateway"} agent model: ollama/gemma4:latest (thinking=medium, fast=off)
12:42:05+00:00 info gateway {"subsystem":"gateway"} http server listening (7 plugins: browser, canvas, device-pair, file-transfer, memory-core, phone-control, talk-voice; 3.1s)
12:42:05+00:00 info gateway {"subsystem":"gateway"} log file: /tmp/openclaw/openclaw-2026-05-15.log
12:42:05+00:00 warn gateway {"subsystem":"gateway"} security warning: dangerous config flags enabled: gateway.controlUi.allowInsecureAuth=true. Run `openclaw security audit`.
12:42:05+00:00 info gateway {"subsystem":"gateway"} starting channels and sidecars...
12:42:05+00:00 info browser/server {"subsystem":"browser/server"} Browser control listening on http://127.0.0.1:18791/ (auth=token)
12:42:05+00:00 info gateway {"subsystem":"gateway"} gateway ready
12:42:05+00:00 info gateway/heartbeat {"subsystem":"gateway/heartbeat"} {"intervalMs":1800000} heartbeat: started
12:42:06+00:00 info cron {"module":"cron","storePath":"/home/elisabeth/.openclaw/cron/jobs.json"} {"enabled":true,"jobs":0,"nextWakeAtMs":null} cron: started
12:42:06+00:00 info gateway/ws {"subsystem":"gateway/ws"} webchat connected conn=ee41b863-7de6-422e-9a05-d628e76d4420 remote=127.0.0.1 client=openclaw-control-ui webchat v2026.5.12
12:42:07+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ sessions.subscribe 422ms conn=ee41b863…4420 id=ecd22ed9…4ed6
12:42:07+00:00 info gateway/ws ```

That looks as normal as it gets

[molten viper]

This chunk is only Gateway startup + Control UI connecting. Nothing here shows the agent run yet.

One thing I do notice: the webchat client reports v2026.5.12 while the CLI/Gateway is 2026.5.14-beta.2. That may just be stale UI assets, but it is worth keeping in mind.

Can you send the next log chunk after 12:42:07, especially the lines around the actual reset/hatch/message? Look for entries mentioning sessions.send, attempt, bootstrap, ollama, chat/completions, or errors/warnings.

A narrower command may be easier than pasting the whole log:

rg -n "sessions\.send|attempt|bootstrap|BOOTSTRAP|ollama|chat/completions|error|warn" /tmp/openclaw/openclaw-2026-05-15.log

That should be short enough to paste and much more diagnostic.

[molten viper]

Yep, startup looks normal. The failure is probably later, at the actual agent attempt.

The status saying 1 bootstrapping is the key: OpenClaw knows bootstrap is pending. So the next useful evidence is whether the agent attempt got the bootstrap prefix/context and then ignored it.

That rg filter should cut through the noise:

rg -n "sessions\.send|attempt|bootstrap|BOOTSTRAP|ollama|chat/completions|error|warn" /tmp/openclaw/openclaw-2026-05-15.log

If that returns almost nothing, try:

tail -n 200 /tmp/openclaw/openclaw-2026-05-15.log

Also, the webchat v2026.5.12 line while the gateway is beta might be stale Control UI assets. I wouldn’t call it the cause yet, but if the logs don’t show the run clearly, rebuilding/reinstalling UI assets may become a suspect.

[zinc mauve]

I spotted something:

12:42:16+00:00 info gateway {"subsystem":"gateway"} gateway ready
12:42:16+00:00 info gateway/heartbeat {"subsystem":"gateway/heartbeat"} {"intervalMs":1800000} heartbeat: started
12:42:16+00:00 info cron {"module":"cron","storePath":"/home/elisabeth/.openclaw/cron/jobs.json"} {"enabled":true,"jobs":0,"nextWakeAtMs":null} cron: started
12:42:16+00:00 info gateway/ws {"subsystem":"gateway/ws"} webchat connected conn=15f5f4ba-3c3f-4582-9d91-3f7937f8eaf2 remote=127.0.0.1 client=openclaw-control-ui webchat v2026.5.12
12:42:17+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ sessions.subscribe 426ms conn=15f5f4ba…eaf2 id=b35468a8…2815
12:42:17+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ health 60ms cached=true conn=15f5f4ba…eaf2 id=27851d4c…1fba
12:42:17+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ agents.list 77ms conn=15f5f4ba…eaf2 id=d1ffc24f…f7f2
12:42:54+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✗ system-presence 1ms errorCode=INVALID_REQUEST errorMessage=missing scope: operator.read conn=42ba0049…0e15 id=14131f3c…a59c

If you point it to the files, it actually reads these.

[molten viper]

Good catch. system-presence ... missing scope: operator.read means that particular Control UI/WebSocket client is connected with a token that lacks read scope. Docs treat that as degraded diagnostics, not a total Gateway failure.

It may explain stale/missing UI state, but I don’t think it directly explains the model ignoring BOOTSTRAP.md, because the agent can read the files when explicitly told. Still worth fixing so the UI/client is not muddying the test:

openclaw devices list

If it shows a pending scope upgrade, approve that request:

openclaw devices approve <requestId>

Docs: https://docs.openclaw.ai/gateway/troubleshooting and https://docs.openclaw.ai/cli/devices

After that, refresh/reopen the Control UI and retry the hatch. If it still gives the generic greeting, the remaining bug report is very clean: bootstrap pending + file present + explicit file read works + injected first-run bootstrap ignored.

[zinc mauve]

nope - I did a /reset and we're back to square one not reading the files.

[molten viper]

Okay, that narrows it: /reset clears the session, but the workspace is still bootstrap-pending, so the next first reply should still follow BOOTSTRAP.md. If it doesn’t, that is reproducible breakage.

I’d do one final isolation test before filing:

openclaw tui

Then send exactly:

Read BOOTSTRAP.md and follow it before replying normally.

If that works, the file access/model can work and the bug is specifically “automatic bootstrap prefix/context not applied or not respected after reset/hatch.”

If that doesn’t work either, it’s the model/context/tool path. Since you’re on ollama/gemma4:latest, testing once with a cloud model or a much stronger local model would be useful evidence.

[molten viper]

Either way, this is now issue-worthy. Include:

• openclaw --version
• openclaw models status
• status says 1 bootstrapping, BOOTSTRAP.md present
• after /reset, first reply is generic instead of following BOOTSTRAP.md
• system-presence missing scope: operator.read appeared, but fixing/refreshing did not change behavior if that’s true

Issue link: https://github.com/openclaw/openclaw/issues

[zinc mauve]

I did dig around in the settings and basically did a visual diff on the old version to the recent one here and there's nothing that strikes me as too different (to the point where it matters)

[molten viper]

That makes sense. I wouldn’t expect the visible config to show this if the break is in the session/bootstrap path.

The useful diff now is runtime state, not settings. Two files/places matter:

ls -la ~/.openclaw/workspace/BOOTSTRAP.md ~/.openclaw/workspace/.openclaw 2>/dev/null
find ~/.openclaw/agents/main/sessions -maxdepth 2 -type f | sort

And for the current session transcript, look for whether OpenClaw recorded a full bootstrap marker or injected bootstrap text:

rg -n "openclaw:bootstrap-context:full|Bootstrap pending|BOOTSTRAP.md|generic greeting text here" ~/.openclaw/agents/main/sessions ~/.openclaw/workspace/.openclaw 2>/dev/null

Expected while bootstrapping:

• BOOTSTRAP.md exists