[BUG] Cowork device bridge: git add silently stages nothing in a connected folder (mount denies unlink)

Product: Claude Cowork, device bridge / connected folders (macOS desktop app)
Date observed: 2026-08-10 · App version: 1.26832.0 (Electron 42.7.0), macOS arm64

Summary

In a folder connected to a Cowork cloud session, git cannot update its index. git add
exits 0 and stages nothing, and every git command leaves a stale .git/index.lock
behind that blocks the next one. The cause is that the mount denies unlink, and git
updates its index by writing index.lock and renaming it over index — a rename that
requires removing the destination.

The silent-success half is the serious part. A user or an agent that trusts git add's exit
code will believe work is staged when nothing is.

Reproduction

In a Cowork session with a git repository connected as a folder, via the device shell:

$ cd <connected-folder>
$ git status --porcelain
warning: unable to unlink '<folder>/.git/index.lock': Operation not permitted
 M .claude-plugin/plugin.json
 ...

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

$ git add README.md
(exit 0, no output)

$ git diff --cached --name-only
(empty)                      # <-- nothing was staged; the add reported success

The lock can be moved but not removed, which is a usable partial workaround for the
blocking half but does nothing for the silent-staging half:

$ mv .git/index.lock /tmp/stale.lock     # succeeds
$ git add -A                              # still does not persist

Expected

Either the mount supports the unlink/rename that git's atomic index update requires, or git
operations that cannot persist fail loudly with a clear message naming the cause. Silent
success is the worst available outcome.

Impact

Any workflow that asks Claude to commit in a connected folder. In my case the whole release
had to be handed back for the user to commit in their own terminal, where git works
normally. It also cost a long diagnosis, because "git add succeeded and staged nothing" is
not a failure mode you look for.

Notes

• rm, rmdir and unlink are all denied on the mount; mv and writes succeed. That

asymmetry is what produces the specific failure — git needs exactly the denied operation.

• Reported guidance suggests running the task on the user's computer instead of in the

cloud avoids the bridge entirely. That is a reasonable workaround but not a fix, and it
is not discoverable from the failure.

• Related, same root cause: tar -x over existing files fails with `Cannot open: File

exists for every file that already exists, since tar also unlinks before creating.
Extracting to a staging directory and cat`-ing each file over its destination works,
because truncating an existing file is a write rather than an unlink.