[BUG] Cowork: allow_cowork_file_delete fails with "Could not find mount for path" when mounted folder name is NFD-normalized (macOS Japanese/accented folder names)

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?

When the Cowork workspace folder name contains Unicode characters stored in NFD (decomposed) form — common on macOS, especially Japanese names containing dakuten/handakuten katakana (ド, ポ, ビ, etc.) — the allow_cowork_file_delete tool always fails with:

Could not find mount for path: /sessions/<id>/mnt/<folder>/<file>. Make sure the path is within a mounted directory.

As a result, file deletion can never be enabled for that workspace. rm in the bash sandbox keeps failing with Operation not permitted (expected before permission is granted), and there is no way to grant the permission.

Root cause (verified by experiments):

The mount lookup appears to compare the file_path argument against the mount registry via exact byte comparison, without Unicode normalization:

1. The macOS folder name is stored as NFD (e.g., ド = e3 83 88 (ト U+30C8) + e3 82 99 (U+3099 combining voiced sound mark)). The FUSE mount inside the VM preserves these NFD bytes (verified with ls /sessions/*/mnt/ | od -An -tx1).
2. The model (Claude) naturally emits NFC when writing the folder name in the tool parameter (ド = e3 83 89 U+30C9).
3. NFC string != NFD registry entry → byte comparison fails → "Could not find mount for path", even though the two strings are visually identical.

Supporting evidence:

• A mounted folder whose Japanese name is normalization-invariant (no dakuten characters, NFC == NFD) works perfectly: allow_cowork_file_delete succeeds and rm works afterwards.
• A mounted folder whose name contains dakuten characters (NFC 13 chars / NFD 16 chars) consistently fails with "Could not find mount for path".
• Passing a non-existent file path under a matching mount root succeeds, confirming the check is a pure string(-prefix) match on the mount root with no filesystem resolution.
• Definitive confirmation: renaming the same folder on macOS to the NFC form of the identical visible name (two-step rename on APFS, verified with od) and re-selecting it in Cowork completely resolved the issue — allow_cowork_file_delete succeeded and rm worked. Only the byte-level normalization of the folder name changed.
• The model cannot reliably emit NFD strings in tool parameters as a workaround — its output is non-deterministically normalized to NFC (verified by byte-level tests), and \uXXXX escapes in string parameters are not decoded. Users cannot self-recover in-session; the lookup itself must normalize.

Impact:

• Any macOS user whose workspace folder name contains NFD characters (Japanese dakuten/handakuten katakana, European accented characters, Korean Hangul, etc.) permanently loses the file-deletion feature in Cowork for that workspace.
• Japanese folder names very frequently contain such characters, so this is effectively a systemic failure for Japanese-named workspaces.

Related issues (same NFC/NFD root cause class, different code paths — not duplicates):

• #29859 — Cowork: cannot create files/folders when workspace path contains accented characters (macOS)
• #18285 — Cowork: Korean folder name encoding issues
• #22243 — VSCode extension: session history lookup fails for NFD paths
• #2224 — Inconsistent Unicode handling across file system tools
• #46788 — allow_cowork_file_delete returns "Permission denied" without dialog (different error path)
• #55206 — Windows: unlink denied on mounted folders (delete gating, not normalization)

What Should Happen?

The mount lookup should normalize both sides (e.g., compare NFC(input) vs NFC(registry)) before comparison, as macOS filenames are frequently NFD while LLM output is almost always NFC. After the user approves, deletion should be enabled regardless of the Unicode normalization form of the folder name.

Error Messages/Logs

$ ls /sessions/<id>/mnt/ | od -An -tx1
... e3 83 88 e3 82 99 ...   # ト + U+3099 (NFD), not e3 83 89 (ド NFC)

Tool call: allow_cowork_file_delete
  file_path: /sessions/<id>/mnt/エンドポイント診断サービス/test.txt   (NFC as emitted by the model)
Result: Could not find mount for path: /sessions/<id>/mnt/エンドポイント診断サービス/test.txt. Make sure the path is within a mounted directory.

$ rm "/sessions/<id>/mnt/エンドポイント診断サービス/test.txt"
rm: cannot remove '...': Operation not permitted   # delete gate never unlockable

$ python3 -c "import unicodedata; print(unicodedata.is_normalized('NFC','<mount name from ls>'))"
False

Steps to Reproduce

1. On macOS, create a folder whose name is NFD on disk (e.g., a Japanese name with dakuten such as エンドポイント診断サービス; verify with ls | od -An -tx1 — look for e3 82 99 / e3 82 9a combining marks).
2. Select the folder as the Cowork workspace in the Claude Desktop app.
3. Ask Claude to delete a file inside it. rm fails with Operation not permitted (expected), so Claude calls allow_cowork_file_delete with the VM path.
4. The tool returns Could not find mount for path: ... and no permission dialog is shown.

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

Claude Cowork 1.22209.3 (babe11)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Verified on 2026-07-21 with two real workspaces on the same machine: a normalization-invariant Japanese folder name (works) vs. a dakuten-containing folder name (always fails), and the NFC rename fix. Full byte-level logs available on request.