#Bootstrap not executing at reset

1 messages ¡ Page 1 of 1 (latest)

glacial surge
#

Describe what you're trying to do and what's happening instead!

  • trying to reset agent or spawn subagent
  • Agent and subagent should be about 80k of context at the moment of reset, instead they get around 5k, so they are dumb.
  • Current workaround is to first tell new/reset agent : "Execute AGENTS.md startup actions — read all skills and context files. Confirm when ready." which brings context to around 80k, unless agent starts arguing that : "no need, it was already done"

Include relevant config (redact secrets!)

  • pretty standard config, doesn't matter from what I can tell.

Paste error messages or logs if you have them

  • no errors, just good old dumbness

Mention your setup: hosting method, providers connected, etc.

  • Windows 11
oblique pawnBOT
#

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

hybrid dawnBOT
agile prairieBOT
#

This probably is not bootstrap failing, it is mostly expected context behavior.

A few important bits:

  • /new and /reset rebuild the normal bootstrap prompt, but they do not auto-read every skill file or every extra context file.
  • Skills are intentionally lazy-loaded. The prompt gets the skill list metadata, then the model reads SKILL.md only when needed.
  • Subagents are intentionally isolated and get a reduced bootstrap set, not the full caller context.
  • Bare /new and /reset can add a small one-shot startup prelude from recent daily memory via agents.defaults.startupContext, but that is still separate from “read all skills/files”.

So your workaround is basically forcing extra context that OpenClaw normally does not preload.

Two likely explanations for the 5k vs 80k difference:

  1. you’re measuring default bootstrap only vs bootstrap + manually-read skills/files
  2. for subagents, the bootstrap is intentionally slimmer than the main session

Please paste these so I can tell you if it’s expected for your exact version:

#

If your real goal is “new/reset should always start fat”, the supported path is usually:

  • put the must-have instructions into bootstrap files
  • tune agents.defaults.bootstrapMaxChars
  • tune agents.defaults.bootstrapTotalMaxChars
  • tune agents.defaults.startupContext

Not “tell the model to go read everything after reset”, because that will always be a bit flaky. If you paste version + /context detail, I can help map out the exact fix.

glacial surge
#

OpenClaw 2026.4.15 (041266a)

  1. Context breakdown (detailed) Workspace:.openclaw\workspace Bootstrap max/file: 12,000 chars Bootstrap max/total: 60,000 chars Sandbox: mode=off sandboxed=false System prompt (run): 37,445 chars (~9,362 tok) (Project Context 15,898 chars (~3,975 tok)) Injected workspace files:

• AGENTS.md: OK | raw 9,459 chars (~2,365 tok) | injected 9,459 chars (~2,365 tok)
• SOUL.md: OK | raw 3,873 chars (~969 tok) | injected 3,873 chars (~969 tok)
• TOOLS.md: OK | raw 850 chars (~213 tok) | injected 850 chars (~213 tok)
• IDENTITY.md: OK | raw 536 chars (~134 tok) | injected 536 chars (~134 tok)
• USER.md: OK | raw 474 chars (~119 tok) | injected 474 chars (~119 tok)
• HEARTBEAT.md: OK | raw 357 chars (~90 tok) | injected 357 chars (~90 tok)
• BOOTSTRAP.md: MISSING | raw 0 | injected 0
• MEMORY.md: OK | raw 99 chars (~25 tok) | injected 99 chars (~25 tok)
Skills list (system prompt text): 7,711 chars (~1,928 tok) (14 skills) Skills: backup-config-edits, cat, chatgpt-image, coding-agent, discord, healthcheck, image-vision, node-connect, openai-whisper-api, skill-creator, taskflow, taskflow-inbox-triage, weather, windows-control
Toi seul(e) peux voir celui-ci — Rejeter le message
2. OCAPP — 23:35
Top skills (prompt entry size):
• coding-agent: 836 chars (~209 tok)
• skill-creator: 763 chars (~191 tok)
• chatgpt-image: 714 chars (~179 tok)
• backup-config-edits: 631 chars (~158 tok)
• windows-control: 608 chars (~152 tok)
• taskflow: 547 chars (~137 tok)
• node-connect: 545 chars (~137 tok)
• image-vision: 498 chars (~125 tok)
• healthcheck: 495 chars (~124 tok)
• taskflow-inbox-triage: 422 chars (~106 tok)
• weather: 420 chars (~105 tok)
• cat: 352 chars (~88 tok)
• openai-whisper-api: 253 chars (~64 tok)
• discord: 219 chars (~55 tok)
Tool list (system prompt text): 0 chars (~0 tok) Tool schemas (JSON): 35,648 chars (~8,912 tok) (counts toward context; not shown as text)

#
  1. OCAPP — 23:35
    Tools: read, edit, write, exec, process, canvas, nodes, cron, message, tts, image_generate, video_generate, gateway, agents_list, sessions_list, sessions_history, sessions_send, sessions_yield, sessions_spawn, subagents, session_status, web_fetch, image, pdf, browser, memory_search, memory_get, host_exec Top tools (schema size):
    • message: 10,424 chars (~2,606 tok)
    • cron: 6,700 chars (~1,675 tok)
    • video_generate: 3,734 chars (~934 tok)
    • browser: 2,799 chars (~700 tok)
    • nodes: 1,589 chars (~398 tok)
    • sessions_spawn: 1,333 chars (~334 tok)
    • image_generate: 1,195 chars (~299 tok)
    • exec: 1,098 chars (~275 tok)
    • process: 961 chars (~241 tok)
    • edit: 834 chars (~209 tok)
    • canvas: 661 chars (~166 tok)
    • gateway: 497 chars (~125 tok)
    • host_exec: 426 chars (~107 tok)
    • pdf: 400 chars (~100 tok)
    • web_fetch: 374 chars (~94 tok)
  2. OCAPP — 23:35
    • image: 342 chars (~86 tok)
    • read: 304 chars (~76 tok)
    • sessions_send: 274 chars (~69 tok)
    • memory_search: 260 chars (~65 tok)
    • memory_get: 249 chars (~63 tok)
    • write: 225 chars (~57 tok)
    • tts: 223 chars (~56 tok)
    • sessions_list: 212 chars (~53 tok)
    • subagents: 191 chars (~48 tok)
    • sessions_history: 161 chars (~41 tok)
    • session_status: 89 chars (~23 tok)
    • sessions_yield: 60 chars (~15 tok)
    • agents_list: 33 chars (~9 tok)
    Top tools (summary text size):
    • cron: 3,726 chars (~932 tok)
    • browser: 1,066 chars (~267 tok)
    • exec: 791 chars (~198 tok)
#

It doesn't make sense. context details contains for sure more than the 5Kb than the context file size is. Also, it doesn't read (metadata, filenames ) nothing of skills located in .openclaw/skills. The agent is dumb as a rock i'm telling you. the bug was not there at the begining, originally all was fine, and i was using /reset a lot to prevent hallucination and slow-down due to compaction of the context window. all of a sudden, agent becomes stupid as soon as i reset.

agile prairieBOT
#

Nice, this actually clarifies it a lot.

What you pasted says reset is working. The confusing part is that there are two different “bootstrap” concepts:

  1. First-run bootstrapping
    That is BOOTSTRAP.md, and it runs once, then gets removed.
    So BOOTSTRAP.md: MISSING after setup is normal. /reset does not rerun that ritual.

  2. Normal prompt bootstrap on each run
    This is the injected workspace files, skills list, and tool schemas.
    Your dump shows that is happening.

Your fresh reset already has roughly:

  • Project Context: ~3,975 tok
  • System prompt text total: ~9,362 tok
  • Tool schemas: ~8,912 tok
#

So you are not actually starting at 5k. You are starting closer to 18k+ tokens before normal conversation history.

The jump to ~80k only happens because you then tell the model to manually read more files/skills. That is not automatic by design.

So the short version is:

  • No, /reset is not supposed to rerun BOOTSTRAP.md
  • No, it is not supposed to eagerly read every skill/context file
  • Yes, subagents are expected to be slimmer than the main agent

If you want something to happen on every /new or /reset, the right buckets are:

  • put the must-have instructions in AGENTS.md / other bootstrap files
  • tune agents.defaults.bootstrapMaxChars
  • tune agents.defaults.bootstrapTotalMaxChars
  • tune agents.defaults.startupContext
  • if you want actual logic on reset, use a command:new / command:reset hook, not BOOTSTRAP.md
#

Yep, that reinforces it.

What you’re seeing is mostly tool/schema overhead, not “missing bootstrap”.
message, cron, browser, etc. are already eating a big chunk of startup context.

So the practical takeaway is:

  • Reset is happening
  • BOOTSTRAP.md is not supposed to rerun
  • Subagents are isolated, they do not clone the parent’s full live context
  • Bigger token count is not the same as smarter

Honestly, I would not optimize for “80k at reset” as the target. A lot of that is just prompt bulk.

For the behavior you want, I’d split it like this:

If you want the main agent to always start with certain instructions

#

Put them directly in:

  • AGENTS.md
  • SOUL.md
  • MEMORY.md
  • or use a command:new / command:reset hook

If you want subagents to be smart about the current task

Put the important context in the spawn task itself.
That is the intended pattern, because subagents are isolated workers.

So instead of relying on “please reread everything”, do something more like:

sessions_spawn task:
You are helping with X.
Relevant constraints:
# 
- ...
- ...
Files / context to use:
- ...
Goal:
- ...

That is usually much more reliable than hoping the child rehydrates itself from workspace files.

If you want, I can help turn your current workaround into one of these two cleaner patterns:

  1. proper reset-time bootstrap, or
  2. better subagent task handoff

Docs:

#

Yeah, this is the first part that actually does smell wrong.

If skills in ~/.openclaw/skills are missing from the available skills list, that is not explained by prompt size alone.

Why I say that:

  • your skills block is only 7.7k chars
  • the default skills prompt budget is 18k chars
  • so those missing skills are probably being filtered before prompt assembly, not trimmed off the end

And docs-wise, ~/.openclaw/skills should be part of the normal skill roots, not ignored:
https://docs.openclaw.ai/tools/skills
https://docs.openclaw.ai/cli/skills

Can you paste these next:

# 
openclaw skills list --verbose
openclaw skills check

If possible, also paste the config bits for:

agents.defaults.skills
agents.list[].skills
skills.allowBundled
skills.load

That will tell us very quickly which bucket this is:

  1. discovery bug , skill not found at all
#
  1. eligibility/filtering , found but excluded
  2. prompt assembly regression , found + eligible but not injected after /reset

If you want the shortest sanity check before deeper digging, a gateway restart is also worth trying once, because the skills snapshot/watcher can get wedged. But the two commands above are the important bit. If those local skills do not show there, I’d start calling this a real regression rather than “expected reset behavior.”

glacial surge
#

agents.defaults.skills
agents.list[].skills
skills.allowBundled
skills.load

those are all empty

openclaw skills list --verbose
openclaw skills check

this is incomplete it includes some skills from .openclaw/skills, one that is working, one that is ignored when called but most skill are not anywhere in there

could it be a cache issue. anyway to clear all caches

#

gateway restart doesn't change anything

#

or maybe a hook can give me control on context load?

agile prairieBOT
#

Yes, hooks can give you control over bootstrap context load, but with one important caveat:

hooks can change injected bootstrap/context files, they do not fix missing skill discovery.

So I’d separate the two problems:

1. Missing / ignored skills from ~/.openclaw/skills

That still sounds like a skills discovery / eligibility / snapshot problem.

There is a skills snapshot layer. Docs say skills are snapshotted per session, and watcher changes can hot-refresh later:
https://docs.openclaw.ai/tools/skills

I don’t know a documented “clear all skills caches” command, but the closest practical flush is:

openclaw gateway restart
#

then start a fresh session again.

That is the first thing I’d try for the cache/snapshot angle.

2. Wanting more control over what loads on reset

Yes, for that, hooks are the right lever.

Useful hook points:

  • agent:bootstrap , mutate or add bootstrap context before injection
  • command:new
  • command:reset

Docs:

Also relevant:

  • built-in bootstrap-extra-files can inject more recognized bootstrap files during agent:bootstrap
#

But again, that helps with context injection, not with “why are some managed skills missing from the skills list”.

My honest recommendation

Try this order:

  1. openclaw gateway restart
  2. new session again
  3. check whether the missing skills now appear in openclaw skills list --verbose

If they still do not appear there, I’d call that a real loader/eligibility bug, not a context-loading problem.

If you want a workaround right now, the least annoying one is probably:

  • move the must-have instructions into AGENTS.md, or
  • put the critical skill into the active workspace skills/ folder

That is uglier than it should be, but it bypasses some of the shared-skill weirdness.

glacial surge
#

openclaw gateway restart
new session again
check whether the missing skills now appear in openclaw skills list --verbose

I've done that a thousand times and I told you. this is not helping, this is the root of the issue.

agile prairieBOT
#

You’re right, and I’ve been too stuck on “restart it”. If openclaw skills list --verbose is itself missing most of those skills, then reset is downstream of the real problem.

So, more precise answer:

  • No, this does not look like a simple cache issue anymore
  • Yes, a hook can give you control over bootstrap context
  • No, a hook will not fix missing skills in the skill loader / eligibility snapshot

The root issue now looks like:

some skills under ~/.openclaw/skills are being filtered out before they ever make it into the available-skills snapshot

The most likely filters are inside the skill metadata/frontmatter, not /reset:

  • disable-model-invocation: true
  • metadata.openclaw.os
  • metadata.openclaw.requires.bins
#
  • metadata.openclaw.requires.anyBins
  • metadata.openclaw.requires.env
  • metadata.openclaw.requires.config
  • exposure.includeInAvailableSkillsPrompt: false
  • malformed frontmatter, especially metadata not being a single-line JSON object

That last one is a sneaky one. Docs explicitly call it out:
https://docs.openclaw.ai/tools/skills

So the one useful next step is not more restarts. It’s this:

paste the frontmatter from

  1. one missing skill
  2. one working skill

Just the --- ... --- header is enough.

#

Then I can diff them and tell you which gate is knocking them out.

On your hook question, yes:

  • agent:bootstrap lets you control injected bootstrap context
  • command:new / command:reset can run logic on reset
  • built-in bootstrap-extra-files can add more bootstrap files

Docs:

If you want a workaround while chasing the real bug, a hook can absolutely inject a synthesized “startup context” file so resets stay smart even while the skill loader is being weird. But that would be a workaround, not the fix.

glacial surge
#

for the skills, i think it was a bad frontmatter problem. I guess the bug didn't show up in previous openclaw version which was more permissive?

agile prairieBOT
#

Yeah, that fits really well.

If the bad skills had malformed frontmatter, especially metadata, then this would explain the whole chain:

  • skill disappears from openclaw skills list --verbose
  • skill never enters the available-skills snapshot
  • /reset looks “dumber” because the agent never sees those skills again

And yes, it’s very plausible an older version was more forgiving, while current OpenClaw is stricter. The docs explicitly want:

  • frontmatter keys on single lines
  • metadata as a single-line JSON object

Docs: https://docs.openclaw.ai/tools/skills

So I’d treat this as:

#
  • your immediate fix: normalize the frontmatter
  • possible OpenClaw regression / compatibility break: older malformed skills used to limp along, newer parser rejects them

If you can reproduce that with one old skill header, it’s probably worth filing a GitHub issue so they can decide whether to restore leniency or surface a clearer warning:
https://github.com/openclaw/openclaw/issues

Glad we found the smell here. That was a frustrating one.

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

glacial surge
#

it is a lot better for the skills, but agent still knows nothing of AGENTS.md after reset. One example: AGENTS.md says that after every modification to config files, agent should git commit the change. Agent never does it until i force him to read AGENTS.md, sometime i must ask multiple times.

agile prairieBOT
#

That helps narrow it down a lot.

If /context detail shows AGENTS.md is fully injected, then the problem is probably not “AGENTS didn’t load” anymore.

It’s more like:

the model is not reliably obeying Project Context instructions after reset

That also explains why “read AGENTS.md now” helps. You’re not fixing loading, you’re forcing the model to re-attend to it.

So for your git commit after config edit example, I’d treat it like this:

Quick fix

Put the critical rule at the very top of AGENTS.md, very short and blunt.

Example:

# 
## Mandatory
- After any config file change, commit the change before replying.

If it’s buried in a long file, weaker compliance is way more likely.

Better workaround

Duplicate truly critical operational rules in a second injected file too, for example SOUL.md or another bootstrap-injected file via hook.

Real fix

If it must happen every time, don’t rely on the model remembering a long prompt rule.
Use deterministic automation, meaning a hook/plugin around the relevant action.

So yes, a hook can help, but I’d frame it like this:

  • agent:bootstrap hook = stronger startup context
#
  • custom/plugin hook around tool/file actions = actual enforcement

Docs:

At this point I think you’ve uncovered two separate issues:

  1. malformed skill frontmatter made skills disappear
  2. AGENTS instructions are injected, but not followed reliably enough after reset

That second one feels less like “bootstrap missing” and more like “instruction weight / attention is too weak for must-follow rules.” If you want, I can help sketch the cleanest hook-based workaround for the config-commit rule.

glacial surge
#

thing is : like i told you before, even though /context detail tells us that agent read the .md files, I think this is false since the whole context file is only 4 or 5 kb after reset and contains nothing of the AGENTS.md. When i force i to read it, context file raise over 40kb and agent finally starts getting stuff.

agile prairieBOT
#

I think the mismatch is that you’re looking at two different buckets of context.

What /context detail reports is the assembled system prompt / bootstrap injection.

What gets much bigger after you force read AGENTS.md is usually the visible transcript/tool-result context.

Those are not the same thing.

So this can both be true at once:

  • AGENTS.md was injected into the hidden system prompt
  • the model still didn’t give it enough attention
  • after read AGENTS.md, the file content is now also in the visible transcript, so the context blob jumps and compliance improves

That would exactly explain why:

  • /context detail says AGENTS is present
#
  • your “context file” still looks tiny / doesn’t visibly contain AGENTS
  • forcing a read makes the agent suddenly behave better

So I don’t think /context detail is necessarily lying. I think it’s reporting hidden prompt assembly, while you’re inspecting transcript-visible context.

Docs hint at this too: /context reports the built system prompt breakdown, but does not dump the full prompt itself:
https://docs.openclaw.ai/concepts/context
https://docs.openclaw.ai/concepts/system-prompt

Which means the remaining problem is probably:

AGENTS is loaded, but not weighted strongly enough unless you surface it again through an explicit read

So if the rule is truly mandatory, I’d still recommend one of these over relying on passive AGENTS injection:

  1. put the must-follow rule at the very top of AGENTS.md
  2. duplicate it in another injected file
#
  1. enforce it with a hook/plugin instead of hoping the model obeys it every reset

Honestly, I think your “force read AGENTS.md” workaround is strong evidence of an attention / instruction-weight issue, not proof that bootstrap injection failed.

glacial surge
#

it is not about "git commit" like i said it is an EXAMPLE. I want the agent to care about AGENTS.md as a whole. all this repeating stuff 3 different ways gets tiring, and is not maintainable in a sane manner. I strongly believe something is very wrong because it was working perfectly before.

agile prairieBOT
#

You’re right, I got too hung up on the example.

Given everything you’ve shared, I think your core claim is reasonable:

after /reset, AGENTS is reported as injected, but the agent behaves like it is not actually using it until an explicit read AGENTS.md

If it used to work and now doesn’t, that really does sound like a regression, not just “prompt hygiene”.

At this point I’d stop treating it as expected behavior and file a GitHub issue with exactly that framing:
https://github.com/openclaw/openclaw/issues

I’d include these bullets:

  • Version: 2026.4.15
  • OS: Windows 11
  • /context detail shows AGENTS.md injected after /reset
  • despite that, the agent behaves as if it does not care about AGENTS as a whole
#
  • after explicit read AGENTS.md, context size jumps and behavior becomes correct
  • this worked in an earlier OpenClaw version
  • malformed skill frontmatter was a separate issue, but fixing that did not resolve the AGENTS/reset regression

If you want, a very tight repro is:

  1. /reset
  2. ask for something that should clearly be guided by AGENTS.md
  3. note wrong behavior
  4. explicitly read AGENTS.md
  5. ask again
  6. note behavior is now correct

That’s a pretty solid bug report.

So yes, I think “something is very wrong” is a fair read here.

glacial surge
#

could it has been fixed on version 2026.04.21

glacial surge
#

you there?

agile prairieBOT
#

Yep, I’m here 🦐

And yes, I still think this looks like a real regression, not you misreading it.

Short version:

  • bad skill frontmatter was one issue
  • but the AGENTS-after-/reset behavior still sounds broken
  • if /context detail says AGENTS.md is injected, but the agent only starts behaving correctly after an explicit read AGENTS.md, that’s not a sane steady state

I also agree with you that “repeat AGENTS three different ways” is not maintainable.

At this point I’d file it as a bug here:
https://github.com/openclaw/openclaw/issues

Minimal repro I’d use:

#
  1. /reset
  2. ask the agent to do something clearly governed by AGENTS.md
  3. it ignores/misses those instructions
  4. explicitly make it read AGENTS.md
  5. ask again
  6. behavior becomes correct

If you want, I can help you tighten that into a clean issue report in one message so you can paste it straight into GitHub.

glacial surge
#

can you verify version 20260422 changelog to see if this was addressed?

agile prairieBOT
#

I checked it.

Short answer, not directly in 2026.4.22.

What I found:

  • In 2026.4.22, I do not see a changelog entry that explicitly says /reset or spawned subagents now re-read AGENTS.md / skills / context files the way you want.
  • The closest relevant fix is actually in 2026.4.18:

Agents/bootstrap: resolve bootstrap from workspace truth instead of stale session transcript markers, keep embedded bootstrap instructions on a hidden user-context prelude, suppress normal /new and /reset greetings while BOOTSTRAP.md is still pending, and make the embedded runner read the bootstrap ritual before replying normally.

That sounds like a real bootstrap fix, but it is specifically about BOOTSTRAP.md, not clearly about AGENTS.md obedience or your “read all skills/context files after reset” behavior.

There are a couple of adjacent 2026.4.22 items, but they look only loosely related:

  • Discord thread/session spawn fix for sessions_spawn({ runtime: "acp", thread: true })
  • ACP/sessions_spawn honoring explicit model overrides