Claude Code Patches a Symlink Bypass in Write Permission Checks
Claude CodeClaude Code 2.1.280 fixed a permission-boundary flaw in which a write through a symlinked path was judged by its in-tree spelling rather than where the write actually landed. Because of that mismatch, acceptEdits mode, configured allow rules, and auto mode could all approve a write that in fact landed outside the directory the user believed they had scoped it to. The permission prompt itself is also now clearer, naming exactly where a write through a symlink will land. This is at least the third distinct symlink-related permission gap Anthropic has patched in Claude Code, following two previously disclosed advisories (CVE-2025-59829 and CVE-2026-25724) in the same permission subsystem.
Key Takeaways
- A write's fate was decided by the wrong path: Claude Code was judging writes through a symlink by the symlink's in-tree spelling, not by where the write actually resolved on disk.
- Three permission surfaces were affected:
acceptEditsmode, configured allow rules, and auto mode could all approve a write that in fact landed outside the intended directory. - The permission prompt is now more honest: it names the real destination of a write through a symlink, so a reviewer sees exactly where it will land before approving.
- This is the third symlink-related permission gap patched in Claude Code: it follows two previously disclosed advisories (CVE-2025-59829 and CVE-2026-25724) affecting different parts of the same permission subsystem.
- The pattern, not just the bug, is the story: each fix covered a different code path (directory deny rules, Bash command spelling, file writes) but the same root cause: a path being judged by its name instead of where it resolves.
- Anyone scoping writes with
acceptEdits, allow rules, or auto mode should update: the fix only ships as of Claude Code 2.1.280 (September 22, 2026).
Sources & Mentions
2 external resources covering this update
The Flaw
Claude Code evaluates most file writes against the path as it appears in the project tree, so that permission rules like acceptEdits, explicit allow rules, and auto mode's own safety checks can reason about "which directory is this write going into." Release 2.1.280 fixed a case where that evaluation used the symlinked path's in-tree spelling rather than the location the write actually resolved to. In practice, this meant a write that a user's rules were meant to keep inside an approved directory could resolve, through a symlink, to somewhere outside it, and still be silently approved by acceptEdits, an allow rule, or auto mode.
The Fix
Claude Code now judges a write by where it actually lands, not by the symlinked path's spelling, and the permission prompt itself now names the real destination so a reviewer can see exactly where a write through a symlink will go before approving it.
Part of a Recurring Pattern
This is not an isolated bug. Anthropic has now shipped at least three separate fixes for symlink-related path validation in Claude Code's permission subsystem: two previously disclosed and tracked as CVE-2025-59829 and CVE-2026-25724, and this write-permission case in 2.1.280. Each involved a different code path (directory deny rules, Bash command spelling, and now file writes through acceptEdits/allow rules/auto mode) but the same underlying category of bug: a permission check reasoning about a path's name instead of where it actually resolves on disk. Users who rely on acceptEdits, allow rules, or auto mode to keep writes inside a specific directory should update to 2.1.280 or later.