openclaw - 💡(How to fix) Fix 2026.5.26: upgrade can create phantom workdir directories; UI displays paths inconsistently across tools

Title

2026.5.26: upgrade can create phantom workdir directories; UI displays paths inconsistently across tools

Summary

After upgrading assistantplatform from 2026.4.23 to 2026.5.26 on macOS Sequoia 15.6 (arm64), two phantom directories appeared under ~/.assistantplatform/ (the legacy on-disk dotted directory):

1. ~/.assistantplatform/workdir/ — a directory literally named workdir (rebranded display form), inode separate from the real workdir/. Created at the moment of the upgrade.
2. ~/.assistant/ (rebranded display form of .assistantplatform) — a dotted dir parallel to the real .assistantplatform, containing only a workdir/ with a memory/ subdir holding exactly two files: self-audit-latest.md and 2026-05-27.md (the latter modified during the first post-upgrade memory-flush operation).

Different tools resolved paths to different directories:

• read / edit (gateway tool layer) consistently hit the real ~/.assistantplatform/workdir/ — but with intermittent ENOENT during/after the upgrade window (likely cache lag).
• write during memory-flush turns landed in ~/.assistantplatform/workdir/memory/ (the phantom).
• exec via $PWD always saw the real workdir.

This caused silent data loss for two writes from the same session:

• memory/self-audit-latest.md (a fresh self-audit run) was written to the phantom; real workdir's copy stayed stale.
• memory/2026-05-27.md (today's daily note) was duplicated across both directories with different content in each.

Reproduction

Hard to reproduce deterministically without an upgrade in-flight. The signal is:

1. Run assistantplatform doctor --repair while a memory-flush write is in progress (or close to it). [Speculative — exact trigger unconfirmed, but doctor --repair was running just before the phantom dirs appeared at the same timestamp as their ctime.]
2. After upgrade completes, check ls -lai ~/.assistantplatform/ for duplicate workspace entries with different inodes.

Evidence (collected from this deployment)

$ ls -lai ~/.assistantplatform/  # (real path; bytes 2e6f70656e636c6177)
11349020 drwx------ 6 <user> staff 192 May 27 21:11 .
11388251 drwx------ 3 <user> staff  96 Apr 15 16:02 agents
14900091 drwx------ 3 <user> staff  96 Apr 29 17:45 credentials
17379862 drwx------ 3 <user> staff  96 May 27 21:11 workspace   <-- PHANTOM (rebranded display name)
11349021 drwx------ 9 <user> staff 288 May 12 13:29 workspace   <-- real

$ os.listdir(b"~/.assistantplatform/")  # raw bytes
[b'agents', b'credentials', b'workspace', b'workdir']
# Display rebrand: 'workdir' = legacy/AssistantPlatform branding (7 bytes ASCII)
#                  'workdir'   = AssistantPlatform rebrand display (also rendered identically in
#                                terminal output but distinct on disk)

Phantom contents:

17379862 workspace/
└── memory/   (created 21:11 BRT)
    ├── self-audit-latest.md  (7883 bytes, 21:11 — duplicate of real)
    └── 2026-05-27.md         (570 bytes, 21:13 — DIFFERENT content from real)

Side effect: file-rendering substitution makes debugging confusing

Workdir-root files are stored under legacy names (HEARTBEAT.md, CONFIG.md, NOTES.md, SETUP.md, PERSONA.md, PROFILE.md, ABOUT.md, MODULE.md) but the UI/chat layer displays them as their AssistantPlatform-rebranded forms (PING.md, CONFIG.md, NOTES.md, SETUP.md, PERSONA.md, PROFILE.md, ABOUT.md, MODULE.md). This is intentional and works fine — the path-resolver translates both ways. The issue is that during the phantom-confusion window, error messages referenced the rebranded names but the actual ENOENT was against a real legacy path, making the problem opaque.

Impact

• Data loss: Two memory writes to the wrong directory; not noticed until 4 hours later.
• Investigation cost: 90+ minutes of model time trying to reconcile path resolution.
• Audit corruption: Self-audit snapshot in the phantom dir was newer than the real one, so the next audit comparison would have referenced stale data if not detected.

Suggested fix

1. On upgrade: detect existing ~/.<legacy>/<...> dir and skip creating any phantom rebrand directory at the same level. Either symlink the new name to the old one, or refuse to create a parallel directory if one with the legacy bytes already exists.
2. Memory-flush write path: validate the target file path resolves under the active workdir (read from the same source as $PWD/runtime workdir env), not from a freshly-cached value at process start.
3. Self-audit hint: add a phantom-detection check (Cortana deployment already added this as self-audit check #14 — see attached). Detect when ~/.<dotdir>/ contains both rebranded and legacy versions of any subdir name.

Workaround for affected deployments

import os
# Always derive paths from the runtime env, never from typed literals
os.chdir(os.environ["PWD"])
# For directory listings, use raw bytes to expose duplicates
for entry in os.listdir(b"."):
    real_name_hex = entry.hex()  # see the actual on-disk bytes

For directories where you suspect phantoms exist:

ls -lai ~/.assistantplatform/ | awk '{print $1}' | sort | uniq -c | sort -rn | head
# If any inode appears more than once with the same display name, you have a phantom

Environment

• macOS Sequoia 15.6 (arm64), Mac Mini
• node v22.22.0
• AssistantPlatform 2026.5.26 (upgraded from 2026.4.23 on 2026-05-27 19:54 BRT)
• APFS (no Unicode normalization tricks; confirmed via raw byte inspection in os.listdir)
• ~6,000+ memory chunks, custom org-internal deployment with on-call coordination agents

Attached evidence

• Backups of both real and phantom 2026-05-27.md: /tmp/workspace-rescue-20260527/
• Self-audit check #14 added to ~/.assistantplatform/skills/self-audit/MODULE.md
• Lessons logged in ~/.assistantplatform/workdir/memory/2026-05-27.md