1. src/infra/exec-approvals.ts, line 281-290 (link)

   realpathSync ENOENT is swallowed, silently skipping the ownership/mode check

   The catch block was designed to tolerate a non-existent path segment (lstatSync → ENOENT). But now fs.realpathSync(current) also lives inside the same try, and it throws ENOENT when ~/.openclaw is a dangling symlink (symlink exists, target directory does not — the state right after stow or chezmoi creates the link but before materialising the target). In that case: lstatSync succeeds and returns isSymbolicLink() === true, then realpathSync throws ENOENT which is caught and swallowed, the ownership/mode assertion is never reached, and mkdirSync(dir) hits the dangling symlink and throws EEXIST — a cryptic failure rather than the clear "Refusing to traverse symlink" message. The fix is to limit the ENOENT swallow to lstatSync by re-throwing any error that originates from inside the symlink-handling branch.

   Prompt To Fix With AI

   This is a comment left during a code review.
   Path: src/infra/exec-approvals.ts
   Line: 281-290
   
   Comment:
   **`realpathSync` ENOENT is swallowed, silently skipping the ownership/mode check**
   
   The `catch` block was designed to tolerate a non-existent path segment (`lstatSync` → ENOENT). But now `fs.realpathSync(current)` also lives inside the same `try`, and it throws ENOENT when `~/.openclaw` is a dangling symlink (symlink exists, target directory does not — the state right after `stow` or `chezmoi` creates the link but before materialising the target). In that case: `lstatSync` succeeds and returns `isSymbolicLink() === true`, then `realpathSync` throws ENOENT which is caught and swallowed, the ownership/mode assertion is never reached, and `mkdirSync(dir)` hits the dangling symlink and throws `EEXIST` — a cryptic failure rather than the clear "Refusing to traverse symlink" message. The fix is to limit the ENOENT swallow to `lstatSync` by re-throwing any error that originates from inside the symlink-handling branch.
   
   How can I resolve this? If you propose a fix, please make it concise.

Best possible solution:

Keep #72572 open and land one rebased, security-reviewed fix against the current assertNoExecApprovalsSymlinkParents() / @openclaw/fs-safe path.

Do we have a high-confidence way to reproduce the issue?

Yes. Source inspection shows exec-policy preset reaches saveExecApprovals(), and current main still rejects a symlinked .openclaw approvals directory before writing.

Is this the best way to solve the issue?

No. The compatibility direction is valid, but this branch is not the best current fix because it targets the removed local path walker, lacks real behavior proof, and needs a security-reviewed current-main implementation.

Security review:

Security review needs attention: The patch changes command-approval filesystem trust boundaries and is stale against the current fs-safe/chmod implementation.

• [medium] Preserve current approvals-directory hardening — src/infra/exec-approvals.ts:232
  The PR head changes the older local path walker, while current main uses the shared fs-safe guard and applies owner-only permissions after creating the approvals directory; a current-main rebuild must preserve those protections.
  Confidence: 0.86
• [low] Do not swallow symlink realpath failures — src/infra/exec-approvals.ts:282
  The proposed symlink branch resolves realpathSync(current) inside an ENOENT-swallowing catch, so a dangling symlink can skip target validation and fall through to a less clear failure path.
  Confidence: 0.78

AGENTS.md: found and applied where relevant.

What I checked:

• Root policy read: Root AGENTS.md was read fully and applied; it requires current-main comparison, whole-surface PR review, security-boundary caution, and real behavior proof for this PR. (AGENTS.md:1, 010b61746379)
• Current main still rejects symlinked approvals directory: Current ensureDir() validates the approvals directory, creates it, then uses fs.lstatSync(dir) and rejects symbolic-link directories. (src/infra/exec-approvals.ts:417, 010b61746379)
• Current wrapper uses fs-safe without the root-child exception: assertNoExecApprovalsSymlinkParents() delegates to assertNoSymlinkParentsSync with allowOutsideRoot and a message prefix, but does not pass allowRootChildSymlink. (src/infra/exec-approvals.ts:435, 010b61746379)
• Current tests encode the unresolved gap: The store tests accept a symlinked OPENCLAW_HOME root but still expect a .openclaw symlink below that boundary to throw. (src/infra/exec-approvals-store.test.ts:646, 010b61746379)
• PR head targets old helper shape: The PR head adds the allowance to assertNoSymlinkPathComponents(), a helper that current main replaced with assertNoExecApprovalsSymlinkParents() backed by @openclaw/fs-safe. (src/infra/exec-approvals.ts:232, f02e100f4369)
• fs-safe refactor provenance: Commit 538605ff44d23e4e57ecfd72a8f0b20159ffebbf extracted filesystem safety primitives and replaced the local exec approvals path walker with the shared fs-safe wrapper. (src/infra/exec-approvals.ts:435, 538605ff44d2)

Likely related people:

• Takhoffman: Commit 4bf94aa0d669 added the local exec-policy CLI and hardened the approvals write path used by the reported command. (role: introduced affected CLI surface; confidence: high; commits: 4bf94aa0d669; files: src/cli/exec-policy-cli.ts, src/infra/exec-approvals.ts, src/infra/exec-approvals-store.test.ts)
• vincentkoc: Commit 364d49889e67 repaired trusted OPENCLAW_HOME symlinks in the same approvals path while leaving the .openclaw child-symlink case rejected. (role: recent symlink-fix contributor; confidence: high; commits: 364d49889e67; files: src/infra/exec-approvals.ts, src/infra/exec-approvals-store.test.ts)
• steipete: Commit 538605ff44d2 extracted the fs-safe primitives now used by current main's exec approvals symlink guard. (role: adjacent filesystem-safety contributor; confidence: high; commits: 538605ff44d2; files: src/infra/fs-safe-advanced.ts, src/infra/exec-approvals.ts)
• jesse-merhi: Commit c9707ab635b9 recently changed command authorization and exec approvals store/tests adjacent to this path. (role: recent adjacent exec approvals contributor; confidence: medium; commits: c9707ab635b9; files: src/infra/exec-approvals.ts, src/infra/exec-approvals-store.test.ts, src/gateway/server-methods/exec-approval.ts)

Codex review notes: model internal, reasoning high; reviewed against 010b61746379.

• The egg game starts only after the PR passes the real-behavior proof check.
• Before that, no creature or rarity is rolled. The treat waits for real proof.
• This is still just collectible flavor: proof affects review readiness, not creature quality.