Issue Station
Sign In
Tools hereToolbox

claude-code - 💡(How to fix) Fix [BUG] Cannot attach files from Google Drive mounted drive (G:) — EXDEV cross-device link error on Windows [2 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#46722•Fetched 2026-04-12 13:34:46
View on GitHub
Comments
2
Participants
2
Timeline
7
Reactions
0
Author
sdcathcartsdcathcart
Participants
github-actions[bot]github-actions[bot]sdcathcartsdcathcart
Timeline (top)
labeled ×3commented ×2cross-referenced ×2

Error Message

Describe the bug: When attaching a PDF file from a Google Drive mounted drive (G:) in Claude Desktop (Cowork), the attachment fails with an EXDEV cross-device link error. Image files from the same G: drive location attach and display correctly. Error message:

Error Messages/Logs

  1. Observe EXDEV error and "Something went wrong" message
  2. Attempt to attach an image file from the same G: location — succeeds without error Related issue: #44407 — Google Drive connector "not connected" state after disconnect/reconnect cycle. This EXDEV error was encountered as a workaround attempt when the native connector was unavailable.

Root Cause

Root cause hypothesis: Images are embedded as base64 directly into the conversation — no filesystem operation required. PDFs are handled differently: Cowork attempts to create a hard link from the G: source path to a local session uploads folder on C:. Windows does not permit hard links across different drive letters. The fix is to use fs.copyFile() instead of fs.link() in the PDF upload handler when source and destination are on different devices.

Fix Action

Fix / Workaround

Related issue: #44407 — Google Drive connector "not connected" state after disconnect/reconnect cycle. This EXDEV error was encountered as a workaround attempt when the native connector was unavailable.

Code Example

EXDEV: cross-device link not permitted, link 'G:\My Drive\Business\Enigma\Decks - Enigma\Enigma Jamaica Deck Update Q4 2025\Enigma Jamaica Investor Deck - Q4 2025.pdf' ->
'C:\Users\sdcat\AppData\Roaming\Claude\local-agent-mode-sessions\[session-id]\uploads\Enigma Jamaica Investor Deck - Q4 2025.pdf'
RAW_BUFFERClick to expand / collapse

Preflight Checklist

  • I have searched existing issues and this hasn't been reported yet
  • This is a single bug report (please file separate reports for different bugs)
  • I am using the latest version of Claude Code

What's Wrong?

<img width="735" height="295" alt="Image" src="https://github.com/user-attachments/assets/089357ac-36b7-4fc3-98a5-697a5fba5be2" />

Describe the bug: When attaching a PDF file from a Google Drive mounted drive (G:) in Claude Desktop (Cowork), the attachment fails with an EXDEV cross-device link error. Image files from the same G: drive location attach and display correctly.

Error message: EXDEV: cross-device link not permitted, link 'G:\My Drive\Business\Enigma\Decks - Enigma\Enigma Jamaica Deck Update Q4 2025\Enigma Jamaica Investor Deck - Q4 2025.pdf' -> 'C:\Users\sdcat\AppData\Roaming\Claude\local-agent-mode-sessions[session-id]\uploads\Enigma Jamaica Investor Deck - Q4 2025.pdf'

Root cause hypothesis: Images are embedded as base64 directly into the conversation — no filesystem operation required. PDFs are handled differently: Cowork attempts to create a hard link from the G: source path to a local session uploads folder on C:. Windows does not permit hard links across different drive letters. The fix is to use fs.copyFile() instead of fs.link() in the PDF upload handler when source and destination are on different devices.

What Should Happen?

Expected behavior: PDFs from G: drive attach successfully, consistent with image behavior.

Error Messages/Logs

EXDEV: cross-device link not permitted, link 'G:\My Drive\Business\Enigma\Decks - Enigma\Enigma Jamaica Deck Update Q4 2025\Enigma Jamaica Investor Deck - Q4 2025.pdf' ->
'C:\Users\sdcat\AppData\Roaming\Claude\local-agent-mode-sessions\[session-id]\uploads\Enigma Jamaica Investor Deck - Q4 2025.pdf'

Steps to Reproduce

Steps to reproduce:

  1. Mount Google Drive via Google Drive for Desktop (appears as G: on Windows)
  2. Open Claude Desktop (Cowork)
  3. Attempt to attach a PDF file from G:\My Drive...
  4. Observe EXDEV error and "Something went wrong" message
  5. Attempt to attach an image file from the same G: location — succeeds without error

Claude Model

Sonnet (default)

Is this a regression?

I don't know

Last Working Version

No response

Claude Code Version

Claude Desktop version: v2.1.92

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

VS Code integrated terminal

Additional Information

Related issue: #44407 — Google Drive connector "not connected" state after disconnect/reconnect cycle. This EXDEV error was encountered as a workaround attempt when the native connector was unavailable.

extent analysis

TL;DR

The most likely fix is to replace fs.link() with fs.copyFile() in the PDF upload handler when the source and destination are on different devices.

Guidance

  • Verify that the issue is indeed caused by the fs.link() call when trying to create a hard link across different drive letters.
  • Check the implementation of the PDF upload handler to confirm that it uses fs.link() and that this is the source of the error.
  • Consider implementing a check to determine whether the source and destination are on the same device before attempting to create a hard link, and use fs.copyFile() instead if they are not.
  • Test the fix by attempting to attach a PDF file from the G: drive after making the suggested change.

Example

const fs = require('fs');
const path = require('path');

// ...

if (isSameDevice(sourcePath, destinationPath)) {
  fs.link(sourcePath, destinationPath, (err) => {
    if (err) {
      // handle error
    }
  });
} else {
  fs.copyFile(sourcePath, destinationPath, (err) => {
    if (err) {
      // handle error
    }
  });
}

// ...

function isSameDevice(path1, path2) {
  const device1 = fs.statSync(path1).dev;
  const device2 = fs.statSync(path2).dev;
  return device1 === device2;
}

Notes

This fix assumes that the issue is indeed caused by the fs.link() call and that replacing it with fs.copyFile() will resolve the issue. However, this may have performance implications if the files being uploaded are very large, as fs.copyFile() will need to read the entire file into memory or use a streaming approach.

Recommendation

Apply the workaround by replacing fs.link() with fs.copyFile() in the PDF upload handler when the source and destination are on different devices, as this is the most straightforward way to resolve the issue without requiring significant changes to the underlying file system or drive configuration.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#configuration error#environment variable#network issue#logging issue

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

claude-code - 💡(How to fix) Fix [BUG] Cannot attach files from Google Drive mounted drive (G:) — EXDEV cross-device link error on Windows [2 comments, 2 participants]