Repository navigation
migrate still leaves ~/ in nodeHost.workerRuns.folders and in list-entry includes of concatenated arrays #972
Description
Summary
#937 covers ~/... config paths that ocm migrate and ocm adopt import copied verbatim into a new environment, where OpenClaw expands ~ against the environment root (OPENCLAW_HOME) instead of the user's home. The fix for #937 (PR #946) spells those values out against the source home for the settings OpenClaw's runtime config treats as paths and for a cited list of settings whose own consumers expand ~. Two cases are still left as written and still move under the environment root after migration.
1. nodeHost.workerRuns.folders
OpenClaw's node worker folder check (src/node-host/node-worker-device-folder.ts) expands a leading ~ with expandHomePrefix(value, { env }), which prefers OPENCLAW_HOME, and then resolves the result with fs.realpathSync.native. Because the consumer resolves symlinks before .., the lexical normalization the migration rewrite applies to other settings would not reproduce its meaning for values containing ... The setting was therefore left out of the rewrite. A plain textual replacement of ~ (without lexical cleanup) would preserve the meaning in every case.
2. An include placed at a list entry of an array that other includes concatenate
The migration rewrite types an include's recorded scope from the resolved config, so an include placed as a list entry is treated as one. When arrays from several includes are concatenated, the recorded index no longer matches the merged position. The include can then be typed as an object key, and its value is left unexpanded. Fixing this needs segment types recorded during include traversal, before merging.
Reproduction
Reproduced on PR #946's head (abfd18d4eb43ebe5bb525ba370db36d28e2e20a1), Linux, debug build, isolated HOME and OCM_HOME:
export HOME=$(mktemp -d) OCM_HOME=$(mktemp -d)
mkdir -p "$HOME/.openclaw" "$HOME/work" "$HOME/bin"
cd "$HOME/.openclaw"
echo '{"gateway":{"port":18789},"nodeHost":{"workerRuns":{"enabled":true,"folders":["~/work"]}},"hooks":{"$include":["./a.json","./b.json"]}}' > openclaw.json
echo '{"items":[{"paths":{"0":"literal"}}]}' > a.json
echo '{"items":[{"paths":[{"$include":"./p.json"}]}]}' > b.json
echo '"~/bin"' > p.json
ocm migrate demo
grep -o '"folders":[^]]*]' "$OCM_HOME/envs/demo/.openclaw/openclaw.json"
cat "$OCM_HOME/envs/demo/.openclaw/p.json"Observed: migration succeeds, the copied config still has "folders":["~/work"], and the copied p.json still contains "~/bin". ocm env exec demo -- env shows OPENCLAW_HOME=$OCM_HOME/envs/demo, and neither $OCM_HOME/envs/demo/work nor $OCM_HOME/envs/demo/bin exists. In the plain install both values named $HOME/work and $HOME/bin.
Expected
Both values keep naming the same location they named in the plain install, as other path settings do after #946.
Impact
Narrower than #937: a node host that reads the migrated environment's config grants its worker access under the environment root instead of the configured folder (or rejects the folder if it does not exist there), and the include layout in case 2 is uncommon. Base main leaves both values unchanged as well; #946 does not make them worse.
Activity
docs: note the ~ settings migration does not rewrite yet
clawsweeper commentedon Nov 2, 2026
Codex review: this still needs some work.
Summary
Keep this issue open: current main preserves the broken path spellings, the linked PR explicitly defers both cases, and the MEMBER author requires maintainer judgment.
Reproducibility: Current source proves unchanged tilde values acquire a different home, and the linked PR reconstructs include types from positions changed by concatenation; the reporter supplies a CLI reproduction, but this review ran none.
Maintainer decision needed
Next step
Coordinate the follow-up with the open migration PR and establish failing migrate/adopt regressions for concatenated includes and preserved worker-folder authorization.
Security
Needs attention: Migrated worker-folder settings can select different consent roots and require authorization-preservation review.
Review details
Best possible solution:
Preserve each path consumer's home and traversal semantics, carrying typed include segments from traversal through migration.
Do we have a high-confidence way to reproduce the issue?
Current source proves unchanged tilde values acquire a different home, and the linked PR reconstructs include types from positions changed by concatenation; the reporter supplies a CLI reproduction, but this review ran none.
Is this the best way to solve the issue?
Repairing migration is appropriate, using consumer-specific prefix expansion and traversal-time include types rather than applying lexical normalization to physical consent paths.
AGENTS.md: found and applied where relevant.
Remaining risk / open question:
Codex review notes: model internal, reasoning medium; reviewed against 4d6362f9f62e.
Label changes
Label changes:
P2: The failures affect custom worker-folder configuration and an uncommon include layout, with the source installation preserved.impact:security: Changing the effective worker-folder root changes the filesystem locations authorized by persisted consent configuration.impact:ux-friction: Migration reports success while affected paths require diagnosis and configuration repair.issue-rating: 🦞 diamond lobster: Current issue advisory state selects this label.clawsweeper:source-repro: Current issue advisory state selects this label.clawsweeper:no-new-fix-pr: Current issue advisory state selects this label.clawsweeper:needs-security-review: Current issue advisory state selects this label.Label justifications:
P2: The failures affect custom worker-folder configuration and an uncommon include layout, with the source installation preserved.impact:security: Changing the effective worker-folder root changes the filesystem locations authorized by persisted consent configuration.impact:ux-friction: Migration reports success while affected paths require diagnosis and configuration repair.Evidence reviewed
Security concerns:
src/store/openclaw_config.rs:205Leaving ~/work unchanged moves its effective root beneath the environment; replacing it through lexical cleanup can also change symlink-before-parent traversal, so verify the original allowed target and nearest forbidden target through the runtime consumer.
Confidence: 0.98
What I checked:
src/store/openclaw_config.rs:2133, 4d6362f9f62e)src/infra/shell.rs:125, 4d6362f9f62e)src/store/openclaw_workspaces.rs:1862, 4d6362f9f62e)src/store/openclaw_config.rs:278, 03c2d19f66bc)src/node-host/node-worker-device-folder.ts:16, a7fe06b17a96)migrateandadopt importkeep~/...paths outside~/.openclaw, which then resolve under the new environment's root #937; searches for workerRuns, tilde, home-relative paths and concatenated arrays found no separate fix owning these exclusions.How this review workflow works
@clawsweeper re-reviewcomments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.@clawsweeper re-reviewor@clawsweeper re-runon an open PR or issue to request a fresh review only.@clawsweeper reviewto request a fresh review only.@clawsweeper explainto ask for more context, or@clawsweeper stopto stop active automation.Reviewed November 2, 2026, 1:36 AM ET / 06:36 UTC.
fix: trim migrated ~ settings the way OpenClaw does
shakkernerd commentedon Nov 2, 2026
One more case belongs here. PR #946 leaves a
~/...value that contains a${VAR}placeholder exactly asmaindoes, for exampleskills.load.extraDirs: ["~/${SKILLS_DIR}/shared"]. OpenClaw replaces the leading~, substitutes the placeholder and only then resolves.., so the lexical expansion the migration rewrite uses for other values could select a different directory (a placeholder such asUP=../..followed by/..would be cancelled before substitution). After migration such a value still expands against the environment root, as it does today. A fix would replace the leading~textually, without lexical cleanup, and check the~/.openclawprefix only on the literal part before the first${.fix: keep list-position includes and trust roots as written during mi…
shakkernerd commentedon Nov 2, 2026
Two more cases are deferred here from #946, both left exactly as
mainleaves them:skills.load.extraDirs: [{"$include": "./dir.json"}]withdir.jsoncontaining"~/shared-skills". The recorded include scope cannot tell a list index from a digit-only object key once arrays from several includes are concatenated (a merged-tree lookup can misclassify in both directions), so fix: ~/ config paths outside ~/.openclaw point at missing locations after migrate #946 types every recorded scope segment as an object key and leaves such values unexpanded. A fix needs the include traversal to record segment types before merging.skills.load.allowSymlinkTargetsandsecurity.installPolicy.exec.trustedDirs. After migration a~/...trust root still names a directory under the environment root, which normally grants nothing (fails closed). Rewriting them changes what is trusted, so it should come with end-to-end proof that allowed targets are admitted and neighboring targets stay rejected.fix: ~/ config paths outside ~/.openclaw point at missing locations a…
fix: keep worker folders as written and name them after migrate
fix: ~/ paths in list-entry includes and placeholder values point und…
shakkernerd commentedon Nov 2, 2026
#983 resolves two of the cases here and turns the other two into explicit warnings, so this issue now tracks only those two.
Resolved in #983.
ocm migrateandocm adopt importnow spell out~/...path values in an include placed at a list position, including arrays concatenated from several includes (include traversal records whether each scope step is a key or a list index before the arrays merge), and~/...values containing a${VAR}placeholder (only the literal directories before the first placeholder are resolved; OpenClaw substitutes and resolves the rest). A placeholder value that leads into~/.openclaw, directly or through a symlink, stays as written and is named in a migration warning, because the placeholder may still lead elsewhere once substituted.Still open here, now reported instead of silent:
nodeHost.workerRuns.folders. OpenClaw resolves these entries to real paths and uses them as a permission boundary, and migration itself changes the links and directories they resolve through (it copies the state directory, relocates absolute state paths into the copy, and imports a linked or external workspace asworkspaces/default). Every rewrite we tried had a layout in which the written entry admitted a folder the plain install rejected, so~/...entries stay exactly as before and migration now printswarning: env <name> keeps the ~/ entries of nodeHost.workerRuns.folders[] as written; .... A fix needs worker-folder resolution that follows the source's links rather than the copied tree's.skills.load.allowSymlinkTargetsandsecurity.installPolicy.exec.trustedDirs. Rewriting them would change what the new environment trusts, so their~/...entries stay as written (they still resolve under the environment root and grant nothing there) and migration now names each such setting in a warning.The workaround for both is to replace the
~/...entries with absolute paths before or after migration.docs/USAGE.mddocuments this limit.