[BUG] Desktop chat (remote devices): delete permission can't be granted on a subfolder of a connected folder, so git leaves .lock files behind

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 the Claude desktop app, in a chat linked to my Mac (remote-devices file tools), delete permission can only be granted on a connected-folder root, never on a subfolder of it.

I connected a parent folder that contains several unrelated repositories. Claude tried to:

• register one repository subfolder with device_request_folder_access. It returned alreadyGranted: true, but the subfolder was NOT registered as a root of its own.
• get delete permission with device_request_delete_permission on that subfolder. It was rejected as "not one of this session's connected folder roots", and no permission dialog was shown.

Without delete permission, git inside that repository cannot remove its own temporary files. Every commit leaves .git/HEAD.lock and .git/objects/maintenance.lock behind, along with tmp_obj_* objects and a zero-byte probe file from git init. The next git command then fails with "File exists".

That leaves two options:

• grant delete on the whole parent folder, which also holds unrelated repositories and sensitive files.
• manually reconfigure connected folders in the desktop app.

What Should Happen?

Either of these:

1. device_request_folder_access on a subfolder registers it as its own root, so delete permission can be granted on just that subfolder.
2. Or a repository's own .git lock and temp files (*.lock, tmp_obj_*) are exempt from the delete block, so git works normally inside a connected folder.

Error Messages/Logs

device_request_folder_access(<parent>/<repo>)  -> alreadyGranted: true
device_request_delete_permission(<parent>/<repo>) -> rejected: path is not one of this session's connected folder roots (no dialog shown)

git (next command after a commit):
fatal: Unable to create '<repo>/.git/HEAD.lock': File exists.

Steps to Reproduce

1. In the Claude desktop app (macOS), connect a parent folder that contains a git repository in a subfolder, e.g. ~/Repos containing ~/Repos/docs-archive.
2. Open a chat linked to this computer and ask Claude to commit a change in ~/Repos/docs-archive using its device shell.
3. The commit succeeds, but .git/HEAD.lock (and sometimes .git/objects/maintenance.lock) is left behind, because rm/unlink inside the connected folder fail with "Operation not permitted".
4. Ask Claude to request delete permission for ~/Repos/docs-archive only. It is rejected as not a connected root, and no dialog appears.
5. Ask Claude to request folder access for the subfolder first. It returns alreadyGranted: true, and step 4 still fails.
6. Run any further git command in the repository. It fails with "File exists" until the lock files are removed by hand.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.296 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Other

Additional Information

Current workaround: after each commit Claude renames the lock files to stale-* (rename is allowed, delete is not), and I delete them by hand later.

Related, but not the same symptom:

• #46788 (delete permission tool returns "Permission denied" without showing a dialog)
• #74324 (Cowork file delete permission dialog never appears)