Hermes writes MEMORY.md as root:root 0600 — breaks the cross-container memory reader; recurs every memory-write turn and defeats default ACLs

[mostlydev]

Summary

When an OpenClaw/Hermes agent container runs as uid=0(root), the runner writes the agent's MEMORY.md (and USER.md) with an explicit mode 0600 (root:root). The container's umask is 0022, so a plain create would be 0644 — the 0600 is deliberate, not a umask artifact. This makes the file unreadable to the non-root process that serves the cross-container agent-memory feed, which then reports "Memory is not available. It may be disabled in config or this environment."

Why the usual mitigations don't hold

A downstream pod added a normalize step (chmod 0666 + a default POSIX ACL u::rwx,g::rwx,o::rwx on each */memory* dir) to fix this. It does not durably hold:

• The default ACL is present on the directory yet a freshly-written MEMORY.md still lands 0600 — an explicit chmod/restrictive-create overrides an inherited ACL.
• It recurs on the agent's own memory-write turn, no restart involved. Verified: normalized dundas/MEMORY.md 0600→0666, and ~13 min later it was back to root:root 0600 (mtime immediately after that agent's floor turn). The most active writer regresses fastest; quiet agents stay at whatever the last normalize left.

So normalize is a band-aid the next write undoes.

Suggested fix (runtime-side)

Either:

• Have the Hermes memory tool write MEMORY.md/USER.md group/world-readable (e.g. 0664/0644) instead of 0600, or
• Have the cross-container memory reader run as / share a group with the writer so owner-only files are still readable, or
• Stop forcing a restrictive explicit mode and let the configured umask apply.

Downstream reference

Tracked desk-side at mostlydev/tiverton-house#49 (originally framed as "restarts that bypass pod-up.sh," now shown to be a per-write-turn runtime behavior).