What
Directory sync between your machine and a cloud session now opens each destination through directory handles instead of resolving paths by name, so a symlink swapped in mid-sync cannot redirect a write outside the synced tree. Where the platform cannot support it, sync falls back to by-name placement limited to root-level files and says so: "File sync on this machine is limited (...)", with reasons such as "a system library could not be loaded" or "this kernel does not enforce the no-symlink open flag". Setting CLAUDE_CODE_DIR_SYNC_DISABLE_ANCHORING turns it off.
Details
- On Linux and WSL destinations are reopened through
/proc/self/fd; on macOS theopenat,mkdirat,renameatandlinkatcalls are loaded from libSystem throughbun:ffi, with a startup probe that checks the kernel actually enforces theO_NOFOLLOW_ANYopen flag. - Every fallback reason has its own user-facing sentence, so a limited sync explains which step failed rather than degrading silently.
- Git commands run inside synced directories are now pinned to an explicit layout (
GIT_DIR,GIT_COMMON_DIR,GIT_WORK_TREE), with filter drivers and hooks neutralised through pinned config keys, and refuse to run at all if a config file inside the work tree would contribute settings. The result is reported astengu_dir_sync_git_layout.
Evidence
this kernel does not enforce the no-symlink open flag
Strings lifted out of the shipped bundle, so the claim above can be checked against them.
Names in the bundleCLAUDE_CODE_DIR_SYNC_DISABLE_ANCHORING
One source agreesOne thing we can check says the same as this entry.
The name it cites is new in this build
New in this build: CLAUDE_CODE_DIR_SYNC_DISABLE_ANCHORING