[BUG] Cowork: local agent mode hardlinks workspace files into its session upload cache, and the cloud file bridge then refuses to read them (nlink > 1)

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?

Summary

Local agent mode does not copy files into a session's upload cache. It creates hard links from the user's workspace files into:

%APPDATA%\Claude\local-agent-mode-sessions\<a>\<b>\local_<session>\uploads\<filename>

Every local session that pulls a file in adds another link, and the links are never removed when the session ends.

The cloud file bridge refuses to read any file with more than one hard link:

file is hardlinked (nlink > 1) — refused to avoid reading through a link alias;
copy the file to break the link and retry

So local mode manufactures exactly the condition that cloud mode is designed to reject. Now that Cowork sessions default to the cloud, files that were previously fine became unreadable with no action by the user and no change to the files themselves. From the user's side this presents as "Claude can't read my connected folder anymore," with no indication of why.

Evidence

A full-tree scan using fsutil hardlink list (excluding node_modules, .wrangler, and .git\objects) found 20 workspace files carrying 52 alias entries. Every single alias pointed into %APPDATA%\Claude\local-agent-mode-sessions\...\uploads\. Not one pointed at a repo, a worktree, an editor folder, or anywhere else.

Representative entry:

[2 links] <workspace>\context\stack.md
      \Users\<USER>\OneDrive\Documents\Claude\context\stack.md
      \Users\<USER>\AppData\Roaming\Claude\local-agent-mode-sessions\<a>\<b>\local_<session>\uploads\stack.md

The accumulation is unbounded. A skill file used by a recurring local scheduled task had reached 26 links, one per run. Two others were at 8 and 3. Files touched by a single interactive session sat at 2.

Sibling files in the same directory that no local session had pulled in were at 1 link and read normally, which is what made the failure look arbitrary from the outside.

Impact

1. Silent loss of context files. Among the 20 affected files were two of the workspace's top-level agent context files, loaded by every session at startup. Cloud sessions had been running for an unknown period without them and without any error surfacing, because the startup routine reads several files and two silently missing ones look like nothing at all. A project-level CLAUDE.md was also affected, meaning that project's governance file had stopped loading entirely.

2. Business documents blocked. The affected set also included legal documents and insurance PDFs. Those were readable by local sessions and unreadable by cloud sessions at the same moment, so the same question could get a confident answer in one mode and "I can't open that file" in the other.

3. Write-through hazard. These are true hard links, not copies. Anything that writes to the cached alias writes through to the user's original file. This is presumably the exact risk the bridge's nlink > 1 guard exists to prevent, which makes it notable that another part of the product is creating the condition.

Workaround

Deleting the alias entries under %APPDATA%\Claude\local-agent-mode-sessions\...\uploads\ restores the files immediately. This is safe by the nature of hard links: the data survives as long as one link remains, so removing the cache entry leaves the workspace original byte-identical and untouched. In our case 52 alias entries were removed, 20 files dropped to a single link, no original changed size, and all 20 became readable from the cloud session at once.

Users should not have to know this. Nothing in the failure message points at local agent mode, and "copy the file to break the link and retry" is not actionable advice for someone who never knowingly created a link.

What Should Happen?

Pick any one of these and the problem goes away:

• Copy rather than hard link into the session upload cache. This also removes the write-through hazard.
• Clean up the session upload cache when a session ends, so links do not accumulate indefinitely.
• Let the bridge resolve the case where every link lives in a Claude-owned location. The guard exists to prevent reading through an unknown alias; a link the product created itself is a known one.

Error Messages/Logs

Steps to Reproduce

1. On Windows, run a local agent mode Cowork session with a connected folder.
2. Have it pull a file from that folder into session context.
3. End the session.
4. fsutil hardlink list "<that file>" — it now reports 2 links, the second inside %APPDATA%\Claude\local-agent-mode-sessions\...\uploads\.
5. Start a cloud Cowork session linked to the same device and try device_stage_files on that file. It is refused with nlink > 1.
6. Repeat steps 1–3 with a recurring/scheduled local task and watch the link count climb by one per run.

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

Claude Desktop | 1.49585.0

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

Environment

| | |
|---|---|
| Claude Desktop | 1.49585.0 |
| Platform | win32 x64 |
| OS | Windows 11 25H2, OS Build 26200.9445 |
| Session type | Cowork cloud session linked to a desktop device |
| Workspace | OneDrive-synced folder, 4,195 files |

Related Issue

This issue could be related: https://github.com/anthropics/claude-code/issues/50268