#/new injecting stale files

1 messages · Page 1 of 1 (latest)

pearl nymph
#

So I'm running my openclaw on wsl. My OS is windows. The problem I'm having is that editing a file that gets auto injected at the start of each session doesn't get picked up by a new session after /new the actual memory file has the edit in it but the version that gets auto injected at the start of each session doesn't contain that edit unless I restart the gateway. Is this normal? Is anyone expierencing something similar?

distant mirageBOT
#

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

rustic badgerBOT
#

This can happen right now, and it’s usually one of two things:

  1. Bootstrap/project-context is snapshotted/cached
    OpenClaw injects workspace “bootstrap files” (AGENTS.md / SOUL.md / USER.md / memory files, etc.) into the prompt. Recent versions added caching of those bootstrap file snapshots per session key to reduce prompt-cache churn (changelog: “cache bootstrap file snapshots per session key…” in 2026.2.23).
    So edits don’t necessarily show up immediately unless that snapshot is invalidated.

  2. WSL + editing from the Windows side (/mnt/c) = flaky file change detection
    If your workspace lives on /mnt/c/... (Windows filesystem) or you edit it with a Windows editor, Linux file watching/mtimes can be weird in WSL, and the Gateway may not notice the change → you see “stale injected” context until a Gateway restart forces a reload.

What I’d try / check:

  • What’s your version? Please paste: openclaw --version
    (If you’re < 2026.2.23, definitely update; if you’re around that version, update anyway in case you’re on a buggy point release.)
  • Where is your workspace located? If it’s on /mnt/c, move it into the WSL Linux filesystem (e.g. the default ~/.openclaw/workspace) and edit it from inside WSL (VS Code “Remote - WSL” is ideal).
  • After editing a bootstrap file, try /new once, and if it’s still stale, do openclaw gateway restart as a workaround.

Docs that describe the intended behavior:

#

If you reply with (a) openclaw --version and (b) whether your workspace is under /mnt/c or under /home/..., I can tell you which bucket you’re in and what the cleanest fix is.

pearl nymph
#

a = 2026.2.26
b = it's installed under Linux/Ubuntu/home/user/.openclaw