Deletions from a cloud session move your files to a session trash, never erasing them.
What's wrong with this entry?
Directory sync can now bring deletions back down to your machine, and it never erases anything: removed files are moved to a per-session trash folder. Each refusal has its own user-facing line, so you can see why a delete was skipped.
- Deletes are refused in bursts, capped per turn, and skipped entirely when no trash folder can be created.
- Skipped for protected names, credential-looking names, symlinked names, and when
.gitsits on a different volume. - Kept, not deleted, when your local copy changed or does not match what Claude removed. Conflicted copies sit beside the files they belong to.
- Bookkeeping (state, staging, trash) lives in a
.ccr-dir-syncdirectory at the top of the working tree, which the model is told to ignore. - Each sync engine has its own enabled check driven by remote config; the archive engine's check raises "directory sync flag unknown just now" when the flag has not resolved yet, so what happens before it resolves depends on the server.
conflicted copies sit beside the files they belong to.
Strings lifted out of the shipped bundle, so the claim above can be checked against them.
Related
Other releases about the same thing. Found by shared names or similar wording; neither means one caused the other.
-
v2.1.238
Sync state machine gains a moved-root case and a per-turn pull hook
Both mention directory
-
v2.1.238
Untracked-file survey extracted and shared
Both mention directory
-
v2.1.238
Sync internals reshaped around per-file credential state
Both mention directory