[BUG] Cowork sandbox: unlink(2) returns EPERM on owned files, breaks .git lock cleanup

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/55206
2. https://github.com/anthropics/claude-code/issues/52322
3. https://github.com/anthropics/claude-code/issues/56324

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Technical Proposal: Cowork Sandbox unlink(2) EPERM Fix

Root Cause

Inside the Cowork sandbox, unlink(2) returns EPERM on files owned by the sandbox user. The cause is an environmental restriction above POSIX — likely seccomp profile, mount options, or container security layer.

Proposed Fix (4-layer approach)

1. Seccomp Profile Patch

• Allow unlinkat syscall for files owned by sandbox UID
• Deny for files owned by other users

2. Mount Option Adjustment

• Ensure sandbox mount has rw flag (not ro or restrictive overlay)

3. Git Workaround (Immediate Mitigation)

• Post-commit hook: truncate orphaned lock files instead of unlinking
• : > "$f" succeeds where rm "$f" fails

4. Sandbox Filesystem Layer Fix

• Patch FUSE/overlay unlink handler to check file ownership
• Allow unlink for sandbox-owned files

Implementation: ~7-10 hours

Quote: $1,500–$3,000

Solution: Handle EPERM on unlink in Cowork Sandbox

Root Cause

When the Cowork sandbox runs as a non-root user, unlink(2) on files owned by a different user (e.g., .git lock files created by the host user) returns EPERM. This breaks .git lock cleanup and can leave the sandbox in a broken state.

Fix

1. Add EPERM handling to the sandbox cleanup logic:

// In the sandbox cleanup/unlink path:
async function safeUnlink(filePath: string): Promise<void> {
  try {
    await fs.unlink(filePath);
  } catch (err: any) {
    if (err.code === 'EPERM' || err.code === 'EACCES') {
      // File is owned by another user — try to change ownership first
      try {
        await fs.chmod(filePath, 0o644);
        await fs.unlink(filePath);
      } catch {
        // If we can't even chmod, log and continue
        // The file will be cleaned up when the sandbox container is destroyed
        logger.warn(`Cannot unlink ${filePath}: ${err.code}`);
      }
    } else {
      throw err;
    }
  }
}

2. Run the sandbox process with a UID/GID that matches the host user:

# In the Cowork VM Dockerfile:
ARG HOST_UID=1000
ARG HOST_GID=1000
RUN groupmod -o -g $HOST_GID cowork &&     usermod -o -u $HOST_UID -g $HOST_GID cowork

3. Use rm -f with force flag for git lock cleanup:

# Instead of: rm .git/index.lock
# Use:
rm -f .git/index.lock 2>/dev/null || true

Why This Works

• EPERM is caught and handled gracefully
• chmod fallback allows unlinking when the process has sufficient privileges
• UID/GID matching prevents the issue at the source
• Force flag provides a last-resort cleanup

Zero Competition

No other solution comments submitted for this issue.

Adding two data points that may help localize this, since the same allowWrite-permits-write-but-not-unlink behavior shows up beyond Claude Code for VSCode.

It also affects Cowork (the Claude desktop app's local sandbox), not just the CLI/VSCode sandbox.

In a Cowork session the host folder is shared into a local Linux VM via virtiofs. Inside the sandbox, the owning user can create and overwrite files but cannot unlink or rename them. For example, "touch .git/x" succeeds, but "rm .git/x" fails with: rm: cannot remove '.git/x': Operation not permitted.

Characteristics match this issue exactly:

The sandbox user owns the parent directory with full rwx (drwx------), so it isn't a POSIX mode problem; unlink is denied above the POSIX layer.

Only unlink-class operations fail (rm, mv over an existing target, rename); content writes, truncation, and chmod all succeed.
It is global across mounts, not folder-specific. It fails in the connected repo folder and also in Cowork's own scratch/output mount (a different path), so it is not the folder's ACLs/flags or its location.
It persists identically across brand-new sessions (each gets a fresh mount).

Practical impact is the same as reported: git cannot complete index updates (it writes index.lock and then renames it over index), so commits cannot be made from inside the sandbox without leaving orphaned .git/*.lock files. git push is separately blocked by network isolation.

On macOS it appears to be OS-version-dependent, and this is the part that might pinpoint it.

Same Claude app version, same repo layout under ~/Documents, two machines:

macOS Sequoia 15.7.7 (Darwin 24): unlink is denied (EPERM), as above.
macOS Tahoe 26.2 (Darwin 26): unlink and rename work normally; in-sandbox git commits succeed with no orphaned locks.

Everything else was ruled out as the differentiator: identical app version, Full Disk Access (the working machine has it off, and enabling it on the failing machine changed nothing), iCloud Drive (disabling it changed nothing), folder ACLs/flags (the failure also occurs in the app's own non-~/Documents scratch mount), and MDM/endpoint-security software (none installed).
If the macOS confinement is a Seatbelt profile granting file-write-data but not file-write-unlink, this suggests Apple changed file-write-unlink enforcement (or its interaction with the profile) between Darwin 24 and Darwin 26, which would explain why the identical build behaves differently across the two OS versions. Happy to run targeted diagnostics or provide session IDs if that would help.

I am having this issue with both dispatch and cowork desktop(on Windows) where it fails or is denied the ability to delete. I get no prompts at all.

i just tried this:

Me: craete a test file and delete it

Claude:
Ran a command
Ran a command
Confirmed — I can create files in your folder but deletion is blocked by the sandbox, regardless of who created the file. You'll need to delete lu381uvr5.tmp manually from File Explorer.

I never get a prompt or anything, I have had to manually deleete things or dig through directories to find ranaom temp/ lock files.

It has the folders in both places, the trusted folders and the cowork files. Is there anyway to fix this issue or is it completely out of the users hands?

This reproduces on Mac as well.
<details>
<summary>Environment</summary>

• Cowork mode, Claude desktop app (macOS)
• Mac Mini
• Model: claude-opus-5
• Date: 2026-07-25
• Context: multi-hour session — subagent web research, editing a local git repo

through a connected folder, running Python, committing

</details>

Still reproducing as of 2026-08-04, and I have a consequence to add that I don't
think is in the original report: git gc / git maintenance never completes, so
the repo is never packed and the garbage accumulates permanently.

Environment

• Host: macOS 15.7.7 (24G720), Apple Silicon
• git 2.55.0 on the host
• Claude Desktop 1.24012.11 (Cowork), Claude Code 2.1.206 on the host
• Repo: a small private local repo (~10 MiB packed), host-side working copy, no worktrees

Consistent with @UFMurphy's Darwin 24 vs Darwin 26 finding above — this machine is
Darwin 24 (24G720), i.e. the failing side of that boundary.

What I found

A Cowork session made 4 commits to this repo across two working windows on
2026-08-04. All 4 commits succeeded — objects written, refs updated, nothing lost.
Afterwards the repo contained:

| Artifact | Count | Size |
|---|---|---|
| .git/objects/{NN}/tmp_obj_* | 126 | 11.63 MiB |
| .git/objects/maintenance.lock | 1 | 0 bytes |
| .git/HEAD.lock / .git/index.lock orphans | 15 | 0 bytes |

git count-objects -vH before cleanup:

count: 133
size: 12.00 MiB
in-pack: 0
packs: 0
garbage: 126
size-garbage: 11.63 MiB

The garbage was 55% of .git. git fsck reported no corruption — the repo was
healthy, just heavily littered.

The part I think is new: maintenance is permanently blocked

Note packs: 0 with 133 loose objects. The orphaned .git/objects/maintenance.lock
was timestamped to the first Cowork session, which means every subsequent
git maintenance run was blocked from that moment on. So the failure is not only
"this session leaves garbage" — it is:

1. Session N orphans maintenance.lock.
2. Every later gc/maintenance run aborts because the lock looks held.
3. Nothing is ever packed or pruned, so tmp_obj_* garbage accumulates without

bound across sessions.

A repo used this way grows monotonically and never self-heals. On the host,
rm -f .git/objects/maintenance.lock && git gc --prune=now took it from 133 loose
objects / 0 packs to 0 loose / 1 pack, and .git from ~21 MiB to 9.7 MiB.

Diagnostic tip: the sandbox stamps commits in UTC

Useful for anyone trying to work out which commits came from Cowork vs. the host:
the sandbox commits with a UTC clock. My host is +0200, and the split is clean:

git log --format='%h %ai'
<hash>  2026-08-04 11:37:24 +0000   <- Cowork
<hash>  2026-08-04 18:26:52 +0000   <- Cowork
<hash>  2026-08-04 18:42:16 +0000   <- Cowork
<hash>  2026-08-04 18:45:56 +0000   <- Cowork
<hash>  2026-08-04 21:05:52 +0200   <- host

Converted to local time, each +0000 commit matches a lock/garbage file mtime to
the minute. That correlation is how I attributed the residue.

Secondary observation (possibly the same root cause, possibly separate)

The Cowork session reported to me that it could not reorganize the repo *because it
was sandboxed* — while it had in fact been committing to that repo successfully all
along. Whatever operation it actually attempted failed with a permission error and
was surfaced as a blanket "I'm sandboxed" rather than as the specific unlink denial.
If the underlying error was the same EPERM on unlink, then the reporting is
masking a fixable, specific failure behind a generic capability statement. I can't
confirm that from outside the sandbox — flagging it in case it helps localize.

Impact as experienced

The residue is invisible until it bites. Nothing warns you. In my case a later
git commit from the host failed outright on a stale .git/index.lock with no git
process running, which is when I went looking. Somebody had already been coping with
it by hand — the repo had lock files moved aside with PID suffixes
(index.lock.10568, stale_index.lock3, …), so it had recurred at least six times
before anyone diagnosed it.

Re-raising the reporter's original question: is git inside Cowork supported, and if
so, what is the sanctioned workflow?