Cowork file tools (Write/Edit) blocked on connected-folder paths containing parentheses

TL;DR

In a Cowork session with a connected folder whose path contains parentheses (eg ~/Library/CloudStorage/Dropbox/Work (DropBox)/AI in Biotech/), the Write and Edit tools fail with:

"Write on <path> is blocked in this session — it resolves to a protected location or a path outside the connected folder."

But the folder IS properly connected. Read, Glob, Grep, and mcp__workspace__bash (via the /sessions/<id>/mnt/... sandbox mount) all work against the same files. Only Write and Edit trip the check.

After renaming the parent folder to remove the parens (eg Work (DropBox) → Work_Dropbox) and reconnecting, Write and Edit work normally on the same project. This isolates the trigger to parentheses in the connected-folder path.

Filed against anthropics/claude-code because there's no Cowork-specific public issue tracker — please redirect to the right team if needed.

Environment

• macOS: 26 Tahoe (host)
• Claude desktop app: 1.8555.1 (cfe7d4) 2026-05-22T17:41:12.000Z
• Cowork mode: local-agent-mode session (not remote)
• Affected folder: ~/Library/CloudStorage/Dropbox/Work (DropBox)/AI in Biotech/ (Dropbox CloudStorage, parens in parent)
• Control folder (same machine, same session): ~/Library/CloudStorage/Dropbox/_Test/ (no parens) — works fine

Reproducer

1. In Finder, create a folder under any local path where one path segment contains parentheses. Eg:

``
~/Library/CloudStorage/Dropbox/Work (DropBox)/AI in Biotech/
``

1. In the Claude desktop app, start a Cowork session and connect that folder.
2. Ask Claude to write any new file under that folder. Eg: Write to "<path>/test.md" with content "hello".
3. Observe: the Write tool returns the "blocked" error above.
4. Ask Claude to Read an existing file under the same folder → succeeds.
5. Ask Claude to run mcp__workspace__bash with a heredoc writing to the same file (via /sessions/<id>/mnt/<folder>/test.md) → succeeds; the file appears on host correctly.
6. Disconnect the folder, rename the parent to remove parens (eg Work (DropBox) → Work_Dropbox), reconnect at the new path.
7. Ask Claude to Write again to the same logical file → succeeds.

Steps 3 and 8 differ only in the presence of parens in the parent-path segment.

Expected behaviour

Write and Edit should succeed in step 3, the same way they do in step 8, and the same way Read and bash already do against the parens-path in steps 5 and 6.

Actual behaviour

Write and Edit return:

"Write on <path> is blocked in this session — it resolves to a protected location or a path outside the connected folder. Work on a copy under the session outputs folder if you need to modify it."

This error is misleading — the path is not protected and is inside a properly connected folder.

Diagnostic matrix (from the 2026-05-24 discovery session)

| Operation | Dropbox/Work (DropBox)/AI in Biotech/ | Dropbox/_Test/ (no parens) |
|---|---|---|
| Read | works | works |
| Glob / Grep | works | works |
| Write | blocked | works |
| Edit | blocked | works |
| mcp__workspace__bash write via /sessions/<id>/mnt/... | works | works |

Both folders are Dropbox CloudStorage paths on the same machine, connected to the same Cowork session. Only the parens differ. After renaming the parent to Work_Dropbox and reconnecting, the previously failing folder behaved identically to _Test.

Suspected root cause

The Cowork file-tool write-side path-allowlist check appears to normalise candidate paths differently from how the read side and the sandbox-mount construction do. Parens in the path produce a mismatch with the stored connected-folder allowlist entry, and the check falls through to the "outside the connected folder" branch.

Inference only — based on symptom shape, not source inspection. Likely the same class of bug for any shell-meaningful character (square brackets, ampersands, etc.); parens are just the case I hit.

Suggested fix area

Whatever code computes "is this candidate path inside the connected folder" for Write and Edit should:

1. Use the same path-normalisation routine as the Read/Glob/Grep side and the sandbox-mount construction.
2. Treat the path as a literal filesystem path, not a glob/shell pattern (parens, brackets, ampersands, spaces should all be inert).
3. Have an integration test fixture with connected folders whose paths contain each of: a space, a parenthesis, a square bracket, an ampersand, and a dollar sign. Run Read, Write, Edit against each.

Bonus: the error message — "resolves to a protected location or a path outside the connected folder" — currently covers two distinct failure modes. If the path is malformed/unrecognised, that should be a different error than "this path is denied by policy." Users currently can't tell which is happening, and assume the folder isn't actually connected.

Workarounds available to users

1. Rename the offending folder to drop parens. Cleanest, but changes the path everywhere downstream (Finder favourites, app shortcuts, scripts, other Cowork connected-folder configs, etc.).
2. Use mcp__workspace__bash heredoc via the sandbox mount instead of Write/Edit. Reliable but adds friction.
3. Use an MCP-native file-write tool that bypasses the Cowork file-tool layer entirely (only viable for files inside that MCP's writable scope).

Reproducibility

100% reproducible within the discovery session. Has not yet been retested on a fresh session or different machine, but the behaviour is environment-level (path-allowlist check), so should reproduce wherever a connected-folder path contains parens.