Bug type

Behavior bug (incorrect output/state without crash)

Summary

openclaw exec-policy preset yolo still fails when ~/.openclaw is a symlink, even after replacement PR #72377 landed and closed #64663.

#72377 fixed only the case where OPENCLAW_HOME itself is a symlinked trusted root. It still rejects a symlinked ~/.openclaw path component under the normal OS home directory, which is a common setup for users who manage OpenClaw config with GNU Stow or similar dotfile tooling.

Steps to reproduce

1. Make ~/.openclaw a symlink, for example:

   ln -s ~/workspace/openclaw-config/openclaw/.openclaw ~/.openclaw

2. Verify the symlink:

   ll ~/.openclaw
   # lrwxr-xr-x@ 1 funjim staff 44B Mar 21 18:28 /Users/funjim/.openclaw -> workspace/openclaw-config/openclaw/.openclaw

3. Run:

   openclaw exec-policy preset yolo

Expected behavior

The command should succeed for a trusted first-level ~/.openclaw symlink owned by the current user, while still rejecting deeper symlink traversal inside the approvals path.

Actual behavior

It fails with:

🦞 OpenClaw 2026.4.26 (6d0e84a) — Your personal assistant, minus the passive-aggressive calendar reminders.

Refusing to traverse symlink in exec approvals path: /Users/funjim/.openclaw

OpenClaw version

2026.4.26 (6d0e84a)

Operating system

macOS

Install method

Any

Model

N/A

Provider / routing chain

N/A

Config file / key location

Exec approvals store under ~/.openclaw/exec-approvals.json

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Local repro:

❯ ll ~/.openclaw
lrwxr-xr-x@ 1 funjim staff 44B Mar 21 18:28 /Users/funjim/.openclaw -> workspace/openclaw-config/openclaw/.openclaw

❯ openclaw exec-policy preset yolo

🦞 OpenClaw 2026.4.26 (6d0e84a) — Your personal assistant, minus the passive-aggressive calendar reminders.

Refusing to traverse symlink in exec approvals path: /Users/funjim/.openclaw

Impact and severity

• Affected: users who keep ~/.openclaw in a git-managed dotfiles repo and expose it via symlink (GNU Stow, chezmoi, manual symlink, etc.)
• Severity: medium — exec approval policy commands fail in a common config-management setup
• Frequency: always, when ~/.openclaw itself is a symlink under the normal home directory

Additional information

What happened across the PRs

• #64663 proposed a broader fix for symlinked exec-approvals paths, including the common ~/.openclaw -> ... setup.
• That PR was later closed and replaced by #72377.
• #72377 merged a narrower change: it allows a symlinked OPENCLAW_HOME trusted root, but still rejects symlinked path components below that root.

The merged PR body explicitly says:

accept a symlinked OPENCLAW_HOME as the trusted approvals root while still rejecting symlinked .openclaw path components below it

That means the common default layout below still fails:

• trusted root: /Users/<user>
• approvals dir: /Users/<user>/.openclaw
• ~/.openclaw is a symlink → still rejected by assertNoSymlinkPathComponents()

Current code path

On current main, ensureDir() still calls:

assertNoSymlinkPathComponents(dir, resolveRequiredHomeDir());

and assertNoSymlinkPathComponents() still rejects the first symlinked component it sees below the resolved home root:

const stat = fs.lstatSync(current);
if (stat.isSymbolicLink()) {
  throw new Error(`Refusing to traverse symlink in exec approvals path: ${current}`);
}

For a normal setup where resolveRequiredHomeDir() is /Users/funjim, the first traversed component is .openclaw, so the command still errors immediately.

Suggested fix direction

Please restore support for a trusted first-level ~/.openclaw symlink, not just a symlinked OPENCLAW_HOME.

A reasonable approach is the broader design from #64663:

• allow the immediate .openclaw child under the trusted home dir to be a symlink
• resolve it with realpathSync
• validate the symlink target is owned by the current user and not group/other-writable
• continue rejecting deeper symlinks inside the resolved .openclaw tree
• ensure the final directory check follows the trusted symlink target safely rather than rejecting it unconditionally

In other words, the current fix handled:

• OPENCLAW_HOME -> /some/real/home ✅

but still misses:

• ~/.openclaw -> ~/workspace/openclaw-config/openclaw/.openclaw ❌

Related

• Replaced PR: fix: allow symlinked OPENCLAW_HOME in exec approvals path check #64663
• Merged replacement: fix: allow trusted exec approvals home symlinks #72377
• Original hardening/regression source: feat: add local exec-policy CLI #64050
• Related but different symlink-path approval issue: [Bug]: Exec approval checks use symlink path but execution uses real path #45595