openclaw - 💡(How to fix) Fix Docker to host migration can leave workspace-local and workspace-local/local paths split, breaking local secrets assumptions [1 participants]

After migrating a local OpenClaw setup from Docker-era state to a native host install, I ran into a second path-layout problem beyond the /home/node/... absolute-path leakage already reported elsewhere.

Summary

The migrated state can leave operational files and assumptions split between:

• ~/.openclaw/workspace-local/
• ~/.openclaw/workspace-local/local/

In my case:

• active writable workspace was ~/.openclaw/workspace-local/local
• a Home Assistant secret still lived at ~/.openclaw/workspace-local/secrets/homeassistant.md
• local operational logic initially assumed the secret should be under the active workspace root, which led to failed lookups and confusing behavior

Why this is a problem

Even when the system mostly works, this split layout creates subtle breakage:

• local docs/instructions may point to the wrong root
• agents may search for secrets in the active workspace and miss them
• warm-up or automation code may succeed only because it still references an older parent path
• troubleshooting becomes confusing because both directories look plausible

Concrete example

Observed working secret path:

• ~/.openclaw/workspace-local/secrets/homeassistant.md

Observed active workspace:

• ~/.openclaw/workspace-local/local

Result:

• agent/user-facing operational assumptions drifted
• secret lookup was performed in the wrong place during troubleshooting
• I had to manually normalize the setup by moving/copying the secret into the active workspace and updating local references to a single canonical path

Expected behavior

Migration or doctor tooling should either:

1. normalize the layout to one canonical workspace root
2. migrate shared secrets/config into the active workspace layout
3. clearly report that secrets/config remain one level above the active workspace
4. provide official guidance for workspace-local vs workspace-local/local

Suggested fixes

• detect split workspace-local / workspace-local/local layouts during migration/startup
• warn when active workspace and secret/config locations are inconsistent
• offer an automatic repair or migration step
• document the canonical expected location for secrets after Docker -> host migration

This looks related to the broader class of migration path/layout issues, but is distinct from the /home/node absolute-path leakage because it affects path conventions and operator expectations even after the runtime is otherwise functioning.