# Cowork folder attach — pitfalls from 2026-08-06 session

## The stale-path trap
Cowork caches folder paths aggressively. After moving a workspace from OneDrive to the vault, re-attaching in the project UI did NOT clear the cached path — the sandbox kept reporting "nothing new mounted" because the VM-side mount never re-established. **Fix: full app quit (tray included), relaunch, re-attach.** Don't iterate attach attempts in a running session.

## Attachments are wiped on full quit
Quitting Claude Desktop completely (to clear a stuck attachment) wiped ALL project folder connections. All 9 projects had to be re-attached. This matches upstream GitHub issues #44933/#47179 (no persistent default folder). Treat Cowork attachments as fragile session state, not durable config.

## Multi-machine path confusion
One Cowork session referenced `C:\Users\rkbla\...` (Surface) while Rob sat at Connie (`C:\Users\Rob\...`). Projects carry paths from whichever machine created them. When an attach fails, first question: "which machine did you create this project on, and which are you on now?"

## Dashboard folder tags lie
The Projects dashboard card footer shows a folder tag for some projects but not others — but the tag presence does NOT correlate with actual attach state. "LinkedIn Posting System" showed no tag but WAS attached. Only trust the project detail screen.