[BUG] [Cowork] Cloud session drops ALL folder grants when one registered project folder path does not exist (Windows)
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
<html>
<body>
<!--StartFragment--><p class="font-claude-response-body break-words whitespace-normal" dir="ltr" data-sourcepos="23:1-23:195;374-568">n a cloud Cowork task, if a project has <strong>two</strong> registered folders and <strong>one of the paths no longer exists on disk</strong>, the session silently drops <strong>all</strong> folder grants — including the valid one.</p>
<p class="font-claude-response-body break-words whitespace-normal" dir="ltr" data-sourcepos="25:1-25:206;570-775"><code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">connectedFolders</code> comes back empty, while the session's own startup context still declares both folders as connected. The result is a session that believes it has folder access, but every file tool fails.</p>
<p class="font-claude-response-body break-words whitespace-normal" dir="ltr" data-sourcepos="27:1-27:47;777-823">Every device-side tool fails at the same gate:</p>
<div dir="ltr" class="overflow-x-auto w-full pl-[var(--msg-block-inset,0.5rem)] pr-2 mb-6 print:overflow-x-visible" data-sourcepos="29:1-34:87;825-1246">
Call | Result
-- | --
get_device_info | "connectedFolders": [] — empty (checked 3× over 13 minutes)
device_list_dir on the registered root | This directory can't be listed without a grant
device_list_dir on its parent | Succeeds — returns directory names with a "not connected to this session" note
device_bash | No folders are connected to this device for the current session.
</div>
<p class="font-claude-response-body break-words whitespace-normal" dir="ltr" data-sourcepos="36:1-36:226;1248-1473">The parent-directory listing is the key detail: <strong>the filesystem is reachable and the paths resolve correctly.</strong> Nothing is wrong with the drive, the mount, or the paths themselves. Only the permission record is inconsistent.</p>
<p class="font-claude-response-body break-words whitespace-normal" dir="ltr" data-sourcepos="38:1-38:103;1475-1577"><strong>Isolating the cause.</strong> Requesting access to <em>only the folder that exists</em> succeeds on the first try:</p>
<div role="group" aria-label="jsonコード" tabindex="0" data-sourcepos="40:1-42:4;1579-1642" class="relative group/copy bg-bg-000/50 border-0.5 border-border-400 rounded-lg focus:outline-none focus-visible:ring-2 focus-visible:ring-accent-100"><div class="sticky opacity-0 group-hover/copy:opacity-100 group-focus-within/copy:opacity-100 top-2 py-2 h-12 w-0 float-right"><div class="absolute right-0 h-8 px-2 items-center inline-flex z-10"></div></div><div class="text-text-500 font-small p-3.5 pb-0">json</div><div class="overflow-x-auto"><pre class="code-block__code !my-0 !rounded-lg !text-sm !leading-relaxed p-3.5" style="color: rgb(20, 24, 31); background: transparent; font-family: var(--font-mono);"><code class="language-json" style="color: rgb(20, 24, 31); background: transparent; font-family: var(--font-mono); white-space: pre;"><span style="color: rgb(43, 48, 59);">{</span><span style="color: rgb(43, 48, 59);">"</span><span style="color: rgb(184, 10, 24);">granted</span><span style="color: rgb(43, 48, 59);">"</span><span style="color: rgb(43, 48, 59);">:</span> <span style="color: rgb(43, 48, 59);">[</span><span style="color: rgb(0, 128, 0);">"G:</span><span style="color: rgb(0, 128, 128);">\\</span><span style="color: rgb(0, 128, 0);">Documents</span><span style="color: rgb(0, 128, 128);">\\</span><span style="color: rgb(0, 128, 0);">workspace</span><span style="color: rgb(0, 128, 128);">\\</span><span style="color: rgb(0, 128, 0);">main_app"</span><span style="color: rgb(43, 48, 59);">]}</span></code></pre></div></div>
<p class="font-claude-response-body break-words whitespace-normal" dir="ltr" data-sourcepos="44:1-44:225;1644-1868">After that grant, <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">connectedFolders</code> is populated and all file tools work normally. Listing that folder then confirms the second registered path is genuinely absent — no directory of that name exists anywhere under the root:</p>
<div role="group" aria-label="コード" tabindex="0" data-sourcepos="46:1-56:4;1870-2214" class="relative group/copy bg-bg-000/50 border-0.5 border-border-400 rounded-lg focus:outline-none focus-visible:ring-2 focus-visible:ring-accent-100"><div class="sticky opacity-0 group-hover/copy:opacity-100 group-focus-within/copy:opacity-100 top-2 py-2 h-12 w-0 float-right"><div class="absolute right-0 h-8 px-2 items-center inline-flex z-10"></div></div><div class="overflow-x-auto"><pre class="code-block__code !my-0 !rounded-lg !text-sm !leading-relaxed p-3.5" style="color: rgb(20, 24, 31); background: transparent; font-family: var(--font-mono);"><code style="color: rgb(20, 24, 31); background: transparent; font-family: var(--font-mono); white-space: pre-wrap;">=== main_app contents ===
.agents .git .gitattributes .gitignore .pytest_cache .venv
DOC_A.md DOC_B.md DOC_C.md DOC_D.md DOC_E.md DOC_F.md
DOC_G.md DOC_H.md requirements.txt
module_one module_two module_three module_four
module_five module_six module_seven shared_data
=== find -name "ProjectAlpha" ===
(no results)</code></pre></div></div>
<p class="font-claude-response-body break-words whitespace-normal" dir="ltr" data-sourcepos="58:1-58:59;2216-2274">So: one broken entry takes the healthy entry down with it.</p>
<blockquote class="ml-2 border-l-4 border-[hsl(var(--border-300)/0.1)] pl-4 text-text-300" data-sourcepos="60:1-60:259;2276-2534">
<p class="font-claude-response-body break-words whitespace-normal" dir="ltr" data-sourcepos="60:3-60:259;2278-2534">Folder names in this report are anonymized. Directory structure, entry counts and all observed behaviour are reproduced exactly. Note that the real paths contain non-ASCII (Japanese) characters in several segments, including the name of the missing folder.</p></blockquote><!--EndFragment-->
</body>
</html>
What Should Happen?
The valid folder should stay granted. The broken entry should be skipped, with a warning naming the missing path.
Specifically:
Do not fail closed across the whole set. Grant the folders that resolve; skip the ones that do not.
Surface the broken entry — e.g. "Folder <path> no longer exists and was skipped" — in the UI and in the session's startup context.
Reconcile the startup context with the device ledger. Today the session is told folders are connected while the device reports none; these two should not be able to disagree.
Offer to repair the project registration when a registered folder is missing (remove it, or point it at a new path).
Error Messages/Logs
Steps to Reproduce
Create a Cowork project named ProjectAlpha. Two folders end up registered on it:
G:\Documents\workspace\main_app — exists
G:\Documents\workspace\main_app\ProjectAlpha — does not exist on disk (same name as the project; never created, or removed later)
Start a cloud Cowork task in that project.
The session startup context declares both folders as connected and available.
Have the agent call any device tool (get_device_info, device_list_dir, device_bash).
All of them fail; connectedFolders is empty.
Claude Model
Opus
Is this a regression?
Yes, this worked in a previous version
Last Working Version
_No response_
Claude Code Version
1.30096.1
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
PowerShell
Additional Information
Related issues. This appears to share a root cause with #40300 (project folder path edits not propagating to the permission entry; closed as not planned), and possibly #33636 and #36313. #40300 describes the same underlying design issue: absolute paths are treated as immutable identifiers, so a stale or missing path leaves an unreconcilable permission entry.
Impact.
The session reports itself as having folder access while having none, so the agent wastes turns diagnosing the user's machine instead of reporting a permission fault. This actively misleads both the agent and the user.
The failure is silent: no warning names the missing path. There is no way to discover the cause from the UI.
Because the healthy folder is dropped too, a single stale entry disables the entire project.
Workaround. Request access to the existing folder only. The grant then succeeds and the session works normally for its duration.