◉CLAUDE LABJP
●2.1.310 — Monitor tool now works on Bedrock, Vertex and Foundry, and gateway failures are fixed (10/23)●2.1.307 — Fixes MCP failing to reconnect after sleep or a keychain lock (10/21). 2.1.306 also fixed the false claude -p login message●SONNET 4.5 — Retires on the Claude API on 11/30, 35 days left. Migrate to Sonnet 5.5●WINDOWS — Reports say hooks break silently only on Japanese-locale Windows; check the character encoding first●API — In API version 2026-10-21, passing temperature, top_p or top_k returns a 400 error●NEW — I Put a Ten-Line Promise File at the To…●2.1.310 — Monitor tool now works on Bedrock, Vertex and Foundry, and gateway failures are fixed (10/23)●2.1.307 — Fixes MCP failing to reconnect after sleep or a keychain lock (10/21). 2.1.306 also fixed the false claude -p login message●SONNET 4.5 — Retires on the Claude API on 11/30, 35 days left. Migrate to Sonnet 5.5●WINDOWS — Reports say hooks break silently only on Japanese-locale Windows; check the character encoding first●API — In API version 2026-10-21, passing temperature, top_p or top_k returns a 400 error●NEW — I Put a Ten-Line Promise File at the To…
Articles/Cowork
◈ Cowork/2026-10-26Beginner

When Cowork Says a Dropbox File Doesn't Exist: The Order I Check Things In

The file is right there in Finder, yet Cowork says it can't find it. The cause may be a Dropbox online-only file. Here is how to tell, how to confirm it with two commands, how to fix it, and where I draw the line on what to share.

Cowork58Dropbox5troubleshooting101file accessMaconline-only

One Monday morning I handed Cowork a folder inside Dropbox and asked it to pull together last month's invoices. The reply was a single line: the file wasn't found at that path.

I opened Finder and there it was. Name, date, everything. And yet, from Cowork's side, it simply didn't exist. I re-granted the folder permission, doubted my settings, and half an hour disappeared before I understood what was going on.

The culprit wasn't Cowork or the permission. It was the state of the file in Dropbox: online-only. If you're stuck at the same spot, here is the order I now follow, from recognizing the symptom to fixing it.

First, check that this is really your problem

Before changing anything, I look at which row of this table my situation matches. If one does, the rest of this article is likely for you.

What you seeMost likely cause
The name shows in Finder, but Cowork says "not found" or can't open itThe file is online-only; no real copy exists on your Mac
Some files in a folder open fine, others don'tThe ones that open are local; the ones that don't are online-only
The folder itself never appearsA wrong folder was granted to Cowork (a different problem)
The filename ends with "conflicted copy"A sync conflict (also a different problem)

The fastest clue is the status column in Finder. A cloud icon next to a file means its contents aren't on your Mac.

Why "visible" doesn't mean "there"

An online-only file is, on your Mac, a bit like a luggage tag with no suitcase attached. It carries a name and a size, but the contents live on Dropbox's servers and are fetched only at the moment something tries to open the file.

That's where two of Cowork's tools behave differently. A shell command looks at what is currently on the disk. A tool that reads a file directly can end up triggering the download as part of opening it. In my own setup, I've repeatedly seen a path fail in the shell and then succeed through the file-reading tool.

The exact behavior may vary with your Dropbox version and macOS settings, so please treat this as a working model rather than a spec. Still, thinking of it as "a tag without a suitcase" makes the diagnosis much simpler than hunting through permission screens.

The order I check things in

There are three steps, and they're short:

  1. Right-click the file in Finder and look at its status.
  2. Ask the terminal whether the contents are really on disk.
  3. Try a second file in the same folder and see whether it behaves the same way.

For the second step, these two commands are enough:

# Show file flags ("dataless" means the contents are not on this Mac)
ls -lO ~/Library/CloudStorage/Dropbox/Invoices/2026-09_CompanyA.pdf
 
# Show real disk usage (0B suggests no local copy)
du -h ~/Library/CloudStorage/Dropbox/Invoices/2026-09_CompanyA.pdf

If ls -lO prints dataless, the file is online-only. The exact output can differ between macOS versions, so if you don't see it, combine the du result with the cloud icon in Finder before deciding.

The third step matters more than it looks. If every file in the folder behaves the same, I suspect the whole folder is online-only. If only a few do, I know I'm dealing with individual files, and I can fix just those.

The fix

Right-click the file or folder and choose "Make available offline." Depending on your Dropbox version the wording may differ, for example "Save locally." Dropbox downloads the contents, and the cloud icon turns into a green check.

Then ask Cowork the same question again. In my case, the "not found" message vanished at that point and nothing else needed changing.

There is one caution I'd like to pass along: don't make a parent folder available offline all at once.

Where I overdid it

The first time I hit this, I panicked and marked the top-level Dropbox folder as available offline. The error did disappear. But free disk space shrank steadily, and my Mac felt sluggish until syncing finished. It was not a good trade.

Here is the line I draw now.

Share with Cowork only the folders that have real files on this Mac.

Concretely, I made a small working folder inside Dropbox that holds only what I'm comfortable letting Cowork see, and I made only that folder available offline. Older documents and large assets stay online-only. The surface Cowork can touch got smaller, and two worries shrank together: running out of disk space, and the chance of showing it a file I'd rather not have read.

If you want an additional habit, I'd suggest a quick look at the folder once a week. Files you no longer use can be switched back to online-only, which gives the space back without deleting anything.

What I'd try today

Open the folder you've granted to Cowork in Finder and scan it once for files with a cloud icon. If you find a few, make just those available offline and send the same request again. I started there too, and it was enough to get me moving.

Share

Thank You for Reading

Claude Lab is ad-free, supported entirely by members like you. We publish practical guides daily with implementation code, benchmarks, and production-ready patterns. If you've found it useful, we'd love to have you on board.

  • ✦Copy-paste ready implementation code
  • ✦New advanced guides published daily
  • ✦$5/mo or $10 for lifetime access
View Membership →

If you found this article helpful, a small tip ($1.50) would mean a lot to us. Your support helps keep this site ad-free and covers server and hosting costs.

Related Articles

◈ Cowork2026-10-25
The Build Stopped on 'Duplicate Resources' — 80+ Conflicted Copies Came From Build Output in a Synced Folder
An Android project inside Dropbox stopped building with a duplicate-resource error. This note covers a scan script that counts the conflicted copies, a pre-build guard that cleans only generated files, and how to exclude folders from sync.
◈ Cowork2026-10-15
Visible in the Listing, Zero Hits by Name: Counting Japanese Filenames With Split Dakuten
In a folder I gave Cowork, Japanese filenames were missing from name searches. Counting about 19,000 entries turned up 17 names with decomposed dakuten. Here is how I counted and fixed it.
◈ Cowork2026-05-06
Claude in Chrome Not Working? A Practical Troubleshooting Guide
Buttons that do nothing, pages that never load, tasks that report success but change nothing. Symptom-by-symptom fixes, plus the 42-run log where adding waits and verification steps moved completion from 62% to 95%.