[DOCS] Sandbox docs omit protection for late-appearing `.claude/*` symlinks

Documentation Type

Missing documentation (feature not documented)

Documentation Location

https://code.claude.com/docs/en/sandboxing

Section/Topic

The Configure sandboxing section's sandbox.filesystem.denyWrite guidance and the Filesystem isolation description of the sandbox's protected paths, including symlink handling for .claude/*.

Current Documentation

The sandbox guide currently says:

You can also deny write or read access using sandbox.filesystem.denyWrite and sandbox.filesystem.denyRead, and re-allow specific paths within a denied region using sandbox.filesystem.allowRead.

It also describes the default write boundary as:

Default write behavior: read and write access to the current working directory and its subdirectories, plus the session temp directory that $TMPDIR points to

The guide does not explain how the sandbox treats symlinks under .claude/ that appear after the sandbox has started.

What's Wrong or Missing?

Claude Code v2.1.210 fixed late-appearing .claude/* symlinks not being reconciled into the sandbox deny-write list. The sandbox documentation explains configurable denyWrite paths and the normal working-directory boundary, but it does not document that .claude/* symlinks are included in the protected write set when they appear during a session.

Without this detail, users cannot tell whether a symlink created or linked after startup is protected automatically, whether writes through the link remain denied, or whether they must add the symlink target manually to sandbox.filesystem.denyWrite. This is especially important for repositories that link shared configuration or generated files into .claude/.

Suggested Improvement

Add a symlink-handling note to the filesystem-isolation section. For example:

Claude Code protects .claude/* symlinks from sandboxed writes by reconciling them into the sandbox deny-write list, including symlinks that appear after the session starts. Writes through those links remain denied; you do not need to list each late-created link separately in sandbox.filesystem.denyWrite.

Clarify whether the protection applies to the link path, its resolved target, or both, and state whether the behavior requires Claude Code v2.1.210 or later.

Impact

Medium - Makes feature difficult to understand

Additional Context

Affected Pages:
| Page | Context |
|------|---------|
| https://code.claude.com/docs/en/sandboxing | sandbox.filesystem.denyWrite configuration and filesystem-isolation write boundary |

Total scope: 1 page affected

The behavior change is documented in Claude Code v2.1.210. The note should distinguish automatic protection of late-appearing .claude/* symlinks from user-configured sandbox.filesystem.denyWrite entries and from the separate permission-rule symlink behavior documented on the permissions page.