[BUG] Cowork Windows: present_files returns "not accessible on the user's computer" for all files — blocks plugin installation

Reproduces on macOS — fresh session, no mounted folder, every path fails

Adding a macOS reproduction with additional detail to support the investigation.

Environment

• macOS 26.3.1
• Claude Desktop 1.5354.0 (9a9e3d) 2026-04-29T01:14:34.000Z
• Cowork session with no workspace folder connected at startup
• Model: claude-sonnet-4-6

What was tried across two sessions

Session 1 (prior): Attempted to install a packaged .skill file via present_files using multiple path strategies:

• Packaged to /tmp/ (file had 644 permissions) → could not complete test; request_cowork_directory for a mounted folder failed mid-session and wedged the bash sandbox
• Packaged to a local folder (file had 600 permissions) → present_files returned "not accessible on the user's computer"
• Tried after quitting and relaunching Claude Desktop → same result

Session 2 (today, fresh): Followed the skill-creator SKILL.md instructions exactly with no connected workspace folder:

1. Staged a minimal valid skill at /tmp/test-skill/SKILL.md
2. Packaged via python -m scripts.package_skill → produced a valid 225-byte .skill file in the session outputs directory
3. Called present_files with the outputs directory path

Result: Cannot present 1 file(s) — not accessible on the user's computer

No connected folder, no multi-folder complexity, no prior session state. Cleanest possible reproduction.

Potential clue: file permissions

In session 1, files packaged directly to /tmp/ had 644 permissions (world-readable), while copies to a local folder had 600. This difference was noticed but never fully tested because the bash sandbox became unstable. It's possible the Cowork host process can't read files with more restrictive permissions from the session VM, but this remains unconfirmed.

Workaround

Manual upload via Customize → Skills → + → select .skill file. This bypasses present_files entirely and works, but requires the user to know the file's path on their Mac and navigate to it manually.

Impact

The present_files + .skill install flow is the only documented path for programmatic skill installation from within a Cowork session. With this broken, the skill-creator skill's "Package and Present" step is a dead end on macOS.

This also compounds #36438, where Claude Code sessions can't install skills at all because present_files isn't available there either. Together these two issues mean there's currently no surface where a Claude session can programmatically complete the skill-creator's install flow end-to-end.

Cross-platform corroboration: same bug on macOS

Adding a same-symptom reproduction from the other side — present_files refusing every canonical path is happening on macOS too, not just Windows. Our session today reproduced the exact failure mode described in your report.

Environment

• macOS host (Darwin)
• Cowork session via Claude Desktop
• Workspace mount type: fuse.bindfs (verified via mount | grep sessions) — not overlayfs, so #37712's "Bug 2" (overlayfs shadow swallowing writes) does not apply to this session
• Three folders selected as userSelectedFolders at session start
• Files in OneDrive CloudStorage path with literal space and dot in path root (~/Library/CloudStorage/OneDrive-<tenant>/CLAUDE_PA/...) — path layout has been stable for months

Reproduction (four cases, same Cowork session, 2026-05-04)

| # | Surface | File type | Size | Mount state | Outcome |
|---|---------|-----------|------|-------------|---------|
| 1 | xxx skill | .pptx | 5.9 MB | folder added mid-session via request_cowork_directory | refused |
| 2 | yyy strip | .pptx | 5.9 MB | folder still mounted from case 1 | refused |
| 3 | zzz skill | .pdf | 287 KB | folder added mid-session via request_cowork_directory | refused |
| 4 | direct present_files call from chat | five files (.py, .md) | 6 KB – 31 KB | all three folders selected at session start | refused |

Case 4 is the architecturally interesting one. Every destination folder was in userSelectedFolders at session boot; none was added via request_cowork_directory. Files refused anyway. This is stricter than the diagnosis in #52956 (which found that only "non-primary" userSelectedFolders mounts were rejected, with the "primary" one still working) — in our session, even files written into the primary workspace folder are refused.

In all four cases:

• Files exist on disk (verified via ls, stat, and the Read tool against the same canonical path moments before the present_files call)
• Files are fully hydrated (verified by reading every byte through cat file > /dev/null immediately before the call — defeats any OneDrive Files-On-Demand placeholder)
• Files are reachable through Read, Edit, and bash from the same session — only present_files refuses

The error string returned every time:

Cannot present N file(s) — not accessible on the user's computer:
  - <canonical absolute path 1>
  - <canonical absolute path 2>
  ...

Architectural diagnosis from #52956 — corroborated and extended

#52956 (closed 2026-04-28 as a duplicate, regrettably — its diagnosis is the most precise on the record) describes the mechanism as:

"The mcp__cowork__present_files MCP tool has been narrowed to accept paths in only two locations: the session's outputs scratchpad (/sessions/<vm-name>/mnt/outputs/) and the single 'primary' workspace folder the session was launched into. Any other folder mounted via userSelectedFolders is rejected."

Our reproduction is consistent with that diagnosis except that even the primary mount appears to be refused for us. Possible explanations: (a) the "primary" determination differs across builds and platforms; (b) a stricter variant of the same regression has shipped since #52956 was filed (2026-04-24); (c) the canonical OneDrive CloudStorage path with CLAUDE_PA/ (literal space + dot) is misclassified by the path normaliser. We do not know which.

The workaround described in #52956 — copy file to /sessions/<vm-name>/mnt/outputs/ first, then call present_files against the scratchpad path — is the only known agent-side mitigation that consistently produces a card. We have not yet tested it in our session because the destination folders here are OneDrive-synced and the user's expectation is that the card opens the OneDrive copy, not the scratchpad copy that vanishes at session end.

Version cluster — same bug class across multiple reports

Listing the public reports we found, with state as of 2026-05-04:

| Issue | Surface | Status | Notes |
|---|---|---|---|
| #50041 (this issue) | present_files: all files refused on Windows | open, regression label | Reporter's machine: Claude Code 2.1.111, started failing 2026-04-17 |
| #52956 | present_files: userSelectedFolders non-primary refused on macOS | closed as dup, NOT locked | Claude Desktop 1.3883.0, started failing ~mid-April 2026; precise architectural diagnosis |
| #37712 | present_files cards never rendered on macOS | closed as dup of #33564, locked-resolved | Claude Code 2.1.81, filed 2026-03-23 — earliest in the cluster |
| #33564 | AskUserQuestion cards not rendered | (the dup target) | Different surface, same bug class (client-side tool registration) |
| #32665 | AskUserQuestion entirely unavailable in Cowork chat | closed as dup of #29393 | Names v1.1.5749 as the regression-introducing build |
| #32837, #32481, #32936 | Cowork v1.1.5749 regressions on Windows VM startup | various | Different surface; same release window; corroborate that v1.1.5749 was a buggy release broadly |

The auto-close-as-duplicate machinery has been merging these into wrong umbrellas — #29393 (subagent silent stall when AskUserQuestion not in --allowedTools) and the original #33564, neither of which fully describes the symptom on the present_files surface specifically. Three independent reports across two MCP tool surfaces (AskUserQuestion, present_files) and two months of reproductions are currently mis-bucketed.

Asks (echoing #50041's existing asks, with additional points)

1. Treat #50041 / #52956 / #37712 / #33564 / #32665 as a single bug class — the client-side MCP tool / path-acceptance regression(s) introduced across v1.1.5749 (per #32665) and Claude Desktop 1.3883.0 (per #52956). Route them to a single owner instead of letting the auto-close machinery split them across #29393 and #33564.
2. Bisect the path-acceptance check in present_files. Per #52956 the change appears to be a narrowing: the tool now accepts only /sessions/<vm>/mnt/outputs/ and the primary workspace folder, rejecting other userSelectedFolders mounts. In our session the narrowing is even stricter (or applied differently) and rejects the primary mount too. Identify the build that introduced the narrowing.
3. Surface a richer rejection reason in the error string. "Not accessible on the user's computer" is misleading because the file IS accessible (Read/Edit/bash all work). A reason code (E_PATH_NOT_IN_ALLOWLIST, E_NON_PRIMARY_USERSELECTED_FOLDER, E_PLACEHOLDER) would let agents recover programmatically.
4. Provide a per-session indicator of mount type (bindfs vs overlayfs). The reporter of #37712 hit "Bug 2" (overlayfs shadow swallowing writes) on a session that used overlayfs. Our session uses bindfs and was unaffected by Bug 2. Sessions on different runtimes need to detect which they are in.

Workaround we deployed agent-side (for context)

We've shipped an agent-side resilience helper that, on present_files refusal:

1. Force-hydrates the file (defeats Files-On-Demand)
2. Resolves symlinks via os.path.realpath() and re-asserts canonical-substring guard
3. Calls present_files with one retry after 1.5s
4. On second failure, appends a structured JSONL incident row and raises a PresentFilesUnavailable exception
5. Calling skills catch the exception and surface the canonical path to chat as plain text:

File saved to: <canonical_path>
Cowork couldn't render the card.
Open it in Finder via: open "<canonical_path>"

This converts a silent invisible-card failure into a visible chat affordance the user can act on. It is a UX mitigation, not a fix. We have NOT yet implemented the #52956 scratchpad-copy workaround; doing so would require accepting that the rendered card opens a vanishing scratchpad copy rather than the OneDrive-synced project copy, which defeats the multi-folder workspace model.

We have a five-row JSONL incident log of refusals from a single session and a five-scenario reproduction harness (Python + Markdown runbook) we'd happily share if anyone on the Cowork team wants reproduction artefacts.

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

Still happening on W11 for download

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.