OpenClaw Main Stops Private Root Memory Loading Into Shared Chats
A merged P1 privacy fix keeps workspace-root MEMORY.md out of group and channel bootstrap context, including supported alias and hook paths.
OpenClaw has merged a P1 privacy repair after workspace-root MEMORY.md was found entering group and channel bootstrap context. That file is intended for the main private session; loading it into a shared model turn could disclose long-term personal or operational context to participants who were never meant to receive it.
The fix is on main. The supplied evidence does not identify a packaged release containing it. Operators who use both private memory and shared channels should treat this as a priority upgrade boundary and review prior shared-session exposure rather than assuming the bug was only theoretical.
What crossed the boundary
The affected path was automatic bootstrap loading. A shared session could receive the root memory file before the model answered, so leakage did not require a participant to call a memory tool or know a secret filename. Relevant private context was already inside the turn.
Upstream issue #84466 and merged PR #119198 establish the defect. The repair keeps direct/private sessions unchanged while excluding the root memory source from group and channel bootstrap lists.
This is separate from project-scoped retrieval. A memory search filter can be correct while the bootstrap layer has already inserted a private file. Operators need both boundaries.
Why the repair is broader than a filename check
The final bootstrap list can be changed by supported loaders and agent:bootstrap hooks. A lexical check alone can fail when the same file arrives through a symlink alias or is relabelled as another allowed bootstrap record.
The merged implementation records the canonical opened source identity, propagates an authoritative chat type, and reapplies privacy policy after hook mutation. Records that still identify the root memory source are removed from non-private bootstrap context even when their path or label changed through supported in-place handling.
Upstream is explicit about the limit: trusted hook code can inject arbitrary bytes, so this is not a sandbox against malicious plugins. It protects OpenClaw-owned loaders and supported relabelling/alias paths; a hostile trusted hook remains trusted code with wider powers.
Interpretation: privacy policy belongs at the final context assembly boundary. Filtering only the initial file list is insufficient when later extensions can mutate that list.
Operator response
If a pre-fix build served both private and shared sessions:
- identify every agent whose workspace root contains sensitive
MEMORY.mdcontent; - identify group and channel sessions handled by those agents during the affected period;
- preserve relevant session and provider audit evidence before deleting anything;
- inspect model-visible bootstrap or prompt evidence where your retention policy lawfully permits it;
- rotate or revoke credentials only when evidence shows they entered a shared turn or downstream log;
- move to a confirmed containing revision; and
- test private and shared sessions with synthetic canary text before restoring normal traffic.
Do not paste the real memory file into tickets, test chats or public incident reports. Use a harmless unique marker in a disposable workspace.
Acceptance test
A useful staging matrix has four cases:
| Context | Fixture | Required outcome |
|---|---|---|
| Main private session | Root MEMORY.md canary |
Canary is available through normal private bootstrap behavior |
| Group or channel | Same root canary | Canary is absent from assembled context and model output |
| Group or channel | Supported symlink alias to root memory | Alias cannot restore the private canary |
| Group or channel | Supported hook relabels the loader-produced record | Final filtering still removes the root source |
Also verify genuine nested shared-safe bootstrap files still work and existing subagent or cron allowlists retain their documented behavior. A repair that removes all memory everywhere is not a successful privacy fix.
Evidence and limits
The official PR page, merged commit and linked issue establish the root-memory exposure, final bootstrap-owner repair and focused tests across direct, group, channel, hook, CLI, compaction, Codex and Copilot bridges. Upstream reports exact-head focused proof; OpenClaw Academy did not inspect a real operator memory store or reproduce disclosure against a live provider.
Relevant collector IDs are 38002, 37972 and 37996.
Bottom line
Shared participants must never inherit the private session’s root memory merely because they use the same agent workspace. Review affected shared sessions, identify a containing build, and prove the final assembled context—not only the initial file list—excludes MEMORY.md before treating the boundary as repaired.
THE RECEIPTS
Claims should survive the click.
Primary links used for this article are listed openly. If the evidence changes, the verification date changes with it.THE OPERATOR BRIEF