claude-code - 💡(How to fix) Fix [BUG] Cowork cannot read Drive Desktop placeholder files; failed reads burn tokens on retries [2 comments, 2 participants]

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

Summary

When a user saves a file to Google Drive Desktop, Cowork (and child Cowork sub-task agents) cannot read the file because Drive Desktop has not yet materialized the file bytes to disk — the file appears in the directory listing as a placeholder cloud reference, but read attempts return "missing %PDF- header" / "file does not exist" errors. The user has to manually open the file in a local viewer to force Drive to download it, then re-prompt Cowork to retry.

This is the highest-severity issue in this bundle because each failed read can trigger a sub-task re-dispatch, each of which consumes a fresh context window. This is the primary driver behind a user having to upgrade their Claude subscription tier — token burn from rework.

Environment

• App: Claude desktop 1.5354.0 (build 9a9e3d, 2026-04-29)
• OS: Windows 11 Home, version 25H2, OS build 26200.8246
• Storage: Google Drive Desktop streaming mode (files-on-demand cloud sync)
• Mode: Cowork mode

Reproduction

1. User saves a PDF / .md / .docx to a Drive Desktop folder (e.g., from Gmail mobile → Drive flow, or saves directly).
2. User asks Cowork to read or analyze the file using the absolute path.
3. Cowork reads the directory listing, sees the file.
4. Read attempt fails: "missing %PDF- header" / "File does not exist" / "is not a valid PDF".
5. User opens the file once locally to force Drive Desktop to download.
6. Re-prompts Cowork.
7. Now works.

Specific examples (logged 2026-05-01)

Example A — Jenny Latham MD Anderson treatment plan PDF:

• File: C:\Users\john3\My Drive\Claude\Projects\Jenny Latham\ca-treatment-breast-invasive-web-algorithm.pdf
• Saved via Gmail mobile → Drive
• First Cowork sub-task dispatch to analyze: failed (placeholder)
• "Available offline" toggle in Drive: did NOT force download in user's experience
• Second sub-task dispatch: still failed
• User attached PDF directly to chat (bypassing Drive): SUCCEEDED, full 27 pages rendered
• 2 wasted Cowork sub-task dispatches before workaround

Example B — Don Call Summary 2026-05-01.md:

• Saved by another Code-mode session to OneDrive (deprecated location) instead of canonical My Drive
• Compounded the placeholder issue with a wrong-location issue
• User had to attach to chat to unblock

Example C — multiple ULC files in Sequel email attachments folder show in directory but fail to open repeatedly

Frequency

Repeatedly throughout the user's time on Cowork. Practically every time they save a new file from another device or attempt to read a recently-cloud-synced file.

Cost impact

• User has had to upgrade Claude subscription tier specifically because of token burn from this and related retry behavior.
• Sub-task dispatches are CHILD Cowork sessions, each with their own context window. When these fail and re-dispatch, the user is paying for each failed attempt.

Suggested investigation

• Can Cowork detect a Drive Desktop placeholder vs a materialized file BEFORE attempting to read? (Windows file attributes flag this — FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS or similar.)
• Can Cowork trigger Drive Desktop's "make available offline" programmatically when about to read?
• Should the Read tool retry with a delay on "missing PDF header" errors before failing?
• Could Cowork warn proactively: "This file appears to be a Drive Desktop cloud placeholder — open it once locally to materialize, then I can read it"?
• Same problem likely exists for OneDrive Files-On-Demand mode — worth checking both.

### Labels
`bug`, `cowork`, `file-system`, `google-drive`, `high-severity`, `cost-impact`


### What Should Happen?

Suggested investigation

- Can Cowork detect a Drive Desktop placeholder vs a materialized file BEFORE attempting to read? (Windows file attributes flag this — `FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS` or similar.)
- Can Cowork trigger Drive Desktop's "make available offline" programmatically when about to read?
- Should the Read tool retry with a delay on "missing PDF header" errors before failing?
- Could Cowork warn proactively: "This file appears to be a Drive Desktop cloud placeholder — open it once locally to materialize, then I can read it"?
- Same problem likely exists for OneDrive Files-On-Demand mode — worth checking both.


### Error Messages/Logs

```shell

Steps to Reproduce

1. Save a PDF or document to a Google Drive Desktop folder (e.g., from another device, or via Gmail mobile → save-to-Drive).
2. Without manually opening the file locally, ask Claude/Cowork to read or analyze the file using its absolute path.
3. Cowork reads the directory listing successfully and sees the file.
4. The Read tool fails with "missing %PDF- header" or "File does not exist" or "is not a valid PDF" — even though the file is visibly in the folder.
5. Manually open the file in any local viewer (Notepad, Adobe, Edge) to force Drive Desktop to download the bytes.
6. Re-prompt Cowork to read the same file.
7. Read now succeeds.

Specific 2026-05-01 example: ca-treatment-breast-invasive-web-algorithm.pdf saved to My Drive\Claude\Projects\Jenny Latham. Two Cowork sub-task dispatches failed before user attached the file directly to chat as workaround.

Claude Model

Not sure / Multiple models

Is this a regression?

No, this never worked

Last Working Version

No response

Claude Code Version

Claude 1.5354.0 (9a9e3d) 2026-04-29T01:14:34.000Z

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

No response