[BUG] Cowork cloud sessions can't read any file written on the linked device: device_stage_files rejects it as hardlinked (nlink > 1)

Status Open
Maintainer reply None cached
Activity 0 comments · opened Oct 8, 2026

Summary

Since Pro/Max Cowork sessions became cloud-only (2026-10-06), a cloud session that writes a file into a connected folder through device_bash cannot bring that file back into the cloud session. device_stage_files refuses every such file:

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

Following the error's own advice does not help: a cp made inside the device VM (stat shows nlink 1 there) is rejected the same way, because on the macOS host every file the VM writes appears with nlink > 1.

This breaks any workflow where the agent generates an image or document locally and then needs to look at it (visual QA of rendered covers or cards, screenshots, charts). Our daily scheduled content pipeline still produces its outputs, but the agent's visual checks silently do nothing. In one run the agent wrote "not visually checked" in its own run notes.

Steps to reproduce

  1. Claude Desktop on macOS, Pro/Max plan, cloud Cowork session, with a local folder connected.
  2. In the session, run via device_bash:

cp some.jpg $HOME/mnt/<folder>/out.jpg (or render any image there)

  1. Call device_stage_files with /Users/<me>/<folder>/out.jpg.
  2. Result: ok: false, error above. The same happens for every file the session previously created in that folder, and after re-copying it inside the VM.

Expected

Files the session itself wrote into a connected folder can be staged back into the cloud session (or Read directly). Otherwise the device bridge is effectively write-only for generated artifacts.

Workaround we're using

Downscale the image on the device, print it as base64 from device_bash, let the oversized tool result spill to a cloud file, decode it there, then Read. It works, but users shouldn't need it.

Possibly related

  • #50268 (Cowork uploads use hard links via fs.link). This may be the same root cause seen from the other direction.

Environment

  • Claude Desktop 2.26454.2 (Electron 44.4.3), macOS arm64
  • Cloud Cowork session linked to the computer, connected folder under ~/Documents
  • Date observed: 2026-10-08

View original on GitHub ↗