[BUG] [Desktop/Windows] Archiving a session leaves its worktree behind when the repo is inside OneDrive

Status Open
Reported on v2.1.286
Maintainer reply None cached
Activity 0 comments · opened Oct 5, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

Archiving a session in the Claude desktop app (Code tab) is supposed to clean up its
worktree under <repo>\.claude\worktrees\. When the repository is inside a OneDrive-synced
folder, the worktree folder and all its files remain for worktrees that OneDrive has
finished syncing. Sometimes the worktree is also unregistered from git, leaving an orphan
folder; sometimes it stays registered with a detached HEAD.

Cause: OneDrive sets the ReadOnly attribute (plus a reparse point) on folders once they
are synced, and git cannot remove a directory that has the ReadOnly attribute.
git worktree remove and git worktree prune both fail with "Permission denied".

Impact: leftover worktrees accumulate silently. In one repo, two leftovers containing
node_modules added about 60,000 files to OneDrive.

What Should Happen?

Archiving a session should remove its worktree folder and the matching admin directory
under .git\worktrees, even when the folders carry the ReadOnly attribute.

Suggested fix: clear the ReadOnly attribute before removal, or fall back to a native
recursive delete (e.g. cmd /c rmdir /s /q, which succeeds) when git reports
"Permission denied", then remove the stale admin directory under .git\worktrees.

Error Messages/Logs

error: failed to delete '<repo>/.claude/worktrees/<name>': Permission denied
error: failed to delete '<repo>/.git/worktrees/<name>': Permission denied

Steps to Reproduce

  1. In a git repository located inside a OneDrive-synced folder (Files On-Demand enabled):

git worktree add --detach .claude\worktrees\t main

  1. Simulate what OneDrive does after syncing:

attrib +r .claude\worktrees\t /d

  1. git worktree remove .claude\worktrees\t

-> exit code 255, "Permission denied", the folder remains

Without step 2 (a freshly created worktree), step 3 succeeds. This explains why
short-lived worktrees are cleaned up on archive and long-lived ones are not.

In the app: start a session that uses a worktree in a repo inside OneDrive, leave it
long enough for OneDrive to sync the folder, then archive the session. The folder
under .claude\worktrees remains.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.286

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Environment: Windows 11, Git for Windows 2.55.0, repository inside OneDrive.
Folders that failed to delete had attributes: ReadOnly, Directory, Archive, ReparsePoint.
A freshly created worktree (attributes: Directory only) was removed without error.

View original on GitHub ↗