[BUG] Scheduled Tasks fail with EXDEV when Documents folder is on a network share (Windows Folder Redirection)

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?

Scheduled tasks fail immediately with EXDEV: cross-device link not permitted when the Windows Documents folder is redirected to a network share (common in enterprise environments with Active Directory / Group Policy folder redirection).

The task never starts executing. Clicking "Erneut versuchen" (Retry) works — only the automatic/initial dispatch fails.

What Should Happen?

Scheduled task should start normally, regardless of whether Documents is local or on a network share.

Error Messages/Logs

EXDEV: cross-device link not permitted, link
'\\fileserver.corp\users\jdoe\Documents\Claude\Scheduled\my-task\SKILL.md'
-> 'C:\Users\jdoe\AppData\Roaming\Claude\local-agent-mode-sessions\<session-uuid>\<run-uuid>\local_<instance-uuid>\uploads\SKILL.md'

Steps to Reproduce

1. Have a Windows machine with Documents folder redirected to a network share (standard enterprise setup via GPO)
2. Create any scheduled task in Claude Desktop (Cowork)
3. Wait for the cron trigger or click "Run now"
4. Task fails immediately with EXDEV error before prompt execution begins

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

Claude Desktop version: Latest (April 2026)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Root Cause

Claude Desktop stores scheduled task definitions (SKILL.md) under %USERPROFILE%\Documents\Claude\Scheduled\. When this path resolves to a UNC network path (e.g., \\server\share\...) due to Windows Folder Redirection, the platform attempts to create a hard link (fs.link) from the network path to a local session path under %APPDATA%\Claude\local-agent-mode-sessions\...\uploads\.

Hard links cannot cross volume/device boundaries on Windows. This is a fundamental OS limitation.

Workaround

Clicking "Erneut versuchen" (Retry) works — the retry apparently bypasses the hard link path
No permanent workaround exists since the Scheduled folder path is hardcoded and not configurable

Suggested Fix

Replace fs.link() with a fallback strategy:

javascripttry {
  await fs.link(source, target);
} catch (err) {
  if (err.code === 'EXDEV') {
    await fs.copyFile(source, target);
  } else {
    throw err;
  }
}

This is the same pattern recommended in related issues (#30584, #25476, #36642, #38030, #18115) for other EXDEV scenarios.

Related Issues

#30584 — Cowork VM download fails with EXDEV (MSIX sandbox)
#25476 — EXDEV when TEMP is on different drive
#36642 — EXDEV on Windows 11 Pro (MSIX install)
#38030 — Workspace fails to start with EXDEV
#25911 — EXDEV on rename during VM bundle setup

All share the same root cause (cross-device fs.link/fs.rename) and the same fix (copyFile fallback).

Impact

This affects any enterprise Windows user with Active Directory folder redirection — a very common setup. No scheduled task can run automatically. The feature is effectively broken for enterprise deployments.Fortschritt7 von 7Konsolidierten Weekly-Briefing-Prompt schreibenScheduled Task weekly-briefing mit neuem Prompt updatenEXDEV-Workaround: Prompt als .md in Vault ablegenDaily morgen-briefing: Mail-Sektion umbauen + Task updatenVault-Zugriff auf Obsidian-MCP umstellen (Prio 1)EXDEV Bug-Report vorbereitenMichael: Modell auf Opus + Arbeitsordner setzen (UI)Arbeitsordnerweekly-briefing-prompt.mdgithub-issue-exdev-scheduled-tasks.mdKontextKonnektorenObsidian MCPM365MCPPpbs-exchangeWeb searchFähigkeitenos-reflexionm365-wochenstart