[BUG] Cowork on Windows: bash sandbox can create files on mounted host folder but unlink is denied — breaks all git write operations

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?

In Cowork on Windows, the bash sandbox can mount a selected host folder and perform read and create-write operations against it, but the unlink syscall is denied at the FUSE/mount layer. POSIX permissions and chmod have no effect — unlink is rejected regardless. sudo is not available (no-new-privs is set on the sandbox).
This is distinct from the reported stale-index.lock issue (#28546), which attributes the symptom to Windows file-handle latency. The behavior here is structural: a brand-new file created microseconds before the unlink attempt, on a path the sandbox just wrote, still fails to unlink. There is no race window where it works.
The practical effect is that all git write operations from the bash sandbox on a mounted Windows folder fail. git add partially succeeds but emits "unable to unlink" warnings on temp objects and .git/index.lock. git commit then fails because the prior .git/index.lock cannot be removed. Subsequent rm -f .git/index.lock from the bash sandbox also fails. Recovery requires the user to open PowerShell and clean up .git/ manually.
This makes the documented "Cowork can manage version control" workflow non-functional on Windows when the repo lives on a mounted host folder.

What Should Happen?

The bash sandbox should be able to perform unlink on paths under the mounted host folder, given that it can already create and write files there. Without unlink, git operations and any other workflow that uses temp/lock files cannot complete inside the sandbox.
If the unlink restriction is a deliberate security measure (preventing the sandbox from deleting host files), it should be documented, and the project-level workflow guidance should be updated to clarify that Cowork on Windows cannot perform git write operations on a mounted host folder.

Error Messages/Logs

$ git commit -m "test"
fatal: Unable to create '/sessions/<session>/mnt/<folder>/.git/index.lock': File exists.

Another git process seems to be running in this repository, e.g.
an editor opened by 'git commit'. ...

$ rm -f .git/index.lock
rm: cannot remove '.git/index.lock': Operation not permitted

Control test demonstrating the structural unlink denial:
$ cd /tmp && touch foo && rm foo && echo "tmp ok"
tmp ok

$ cd /sessions/<session>/mnt/<folder> && touch foo && rm foo
rm: cannot remove 'foo': Operation not permitted

Same file, freshly created microseconds before the unlink. POSIX permissions and chmod have no effect.

Steps to Reproduce

On Windows 11 (any recent build with WSL2 / Hyper-V Platform installed), open Cowork.
Select a folder that is a git repo (any folder under C:\Users\<you>\... works — does not need to be in OneDrive or Downloads, which have their own known mount issues).
Start a session and run the following control test in the bash tool:

uname -a
cd /tmp && touch foo && rm foo && echo "tmp ok"
cd /sessions/<session>/mnt/<folder> && touch foo && rm foo && echo "mnt ok"

The first rm succeeds. The second fails with rm: cannot remove 'foo': Operation not permitted.

Now reproduce the git failure:

cd /sessions/<session>/mnt/<folder>
echo "# test" >> .gitignore
git add .gitignore
git commit -m "test"

git add will emit unlink warnings; git commit will fail with Unable to create '.git/index.lock': File exists.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.121 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

This is a Cowork-on-Windows bug. The form fields lean toward the Claude Code CLI but the Cowork sandbox runs Claude Code under the hood, so the same repo is the right place — see prior Cowork-tagged issues like #28546, #25096, #25293, #41710, #42520, #45433, #50873.

Related-but-distinct issues searched and ruled out as duplicates:

• #28546 (stale .git/index.lock on Windows) — closest match, but reporter attributes the cause to Windows file-handle latency. The control test in this report (touch foo && rm foo on a brand-new file in the mount) rules that out: there's no race window, the unlink is structurally denied.
• #11005 (closed NOT_PLANNED) — Linux/macOS scope, different platform.
• #41710, #42520, #45433, #50873 — FUSE cache coherency / stale content issues. Different symptom (read returns wrong data); this report is a write-side issue (unlink denied).
• #25xxx series — virtiofs/Plan9 mount-fails-to-establish issues. The mount in this report establishes successfully; the issue is what's allowed once it's mounted.

The repo I tested against is on local disk under the user profile (NOT OneDrive, NOT Downloads), so the special-folder mount issues don't apply.

Repro environment: Windows 11, WSL2 newly installed (Cowork's bash sandbox booted successfully on first session after the install), Cowork session in a fresh chat, no other modifications.