[BUG] Cowork Scheduled Task — SKILL.md Not Accessible From Session VM (Windows, Non-Standard Documents Path)

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

Cowork scheduled tasks fire on time, but the session VM cannot read the task's SKILL.md prompt file. The session falls back to inferring intent from the task name and list_scheduled_tasks description, producing degraded output that lacks the full prompt instructions.

Environment

• OS: Windows 11, Desktop app
• Plan: Team (Opus 4.6)
• Cowork version: Current as of March 15, 2026
• Key detail: Windows Documents folder is redirected to E:\Documents\ (not C:\Users\<user>\Documents\). System drive (C:) is kept clean for OS-only.

Observed Behavior

The session logs show this sequence:

1. "Let me read the SKILL.md file first" → Read SKILL.md (failed)
2. "Find the morning-inbox-briefing SKILL.md" → Script (failed)
3. "Find the scheduled task file" → Script (failed)
4. "List scheduled tasks directory" → Script (failed, red)
5. "The scheduled task file isn't accessible from the filesystem."
6. Falls back to list_scheduled_tasks → gets task name + description only
7. Improvises from description — output lacks formatting, triage rules, and business context from the full prompt

This behavior is 100% reproducible across 3 consecutive runs (Mar 14 x2, Mar 15).

Root Cause Analysis

Two issues compound to create this failure:

Issue 1: SKILL.md stored outside VM-accessible boundary

The task file is stored at E:\Documents\Claude\Scheduled\morning-inbox-briefing\SKILL.md. The Cowork VM can only mount directories under the Windows home directory (C:\Users\<user>\). Attempting to mount E:\Documents\ returns: "Selected directory is outside the home directory and cannot be mounted."

This affects any Windows user whose Documents folder is on a non-system drive — a common power user configuration for backup, SSD management, and OS reinstall workflows.

Issue 2: Scheduler doesn't inject prompt content into session

Even if the file path were accessible, the scheduler appears to pass only the task name and metadata to the session, not the prompt content. The session is told to "read the scheduled task file" but the file doesn't exist in the VM. The prompt content should be injected directly into the session context by the scheduling infrastructure, regardless of filesystem path.

Workaround

We found a functional workaround:

1. Save the full prompt as a separate .md file in a folder under C:\Users\<user>\ (inside the home directory boundary)
2. Set the task's "Folder to work in" to that directory via the Edit form
3. Update the task description to include: "If you cannot read the SKILL.md file, look for <filename>.md in your working folder and execute its instructions"
4. Session fails to read SKILL.md → calls list_scheduled_tasks → reads description → reads prompt file from working folder → executes full instructions

This works but is fragile — the session is routing around the bug rather than the platform working correctly.

Note: Even with the working folder correctly configured in the Edit form, the session still shows "Scratchpad" in the UI sidebar, suggesting the working folder setting may not be fully propagating to the VM mount.

Impact

• Scheduled task prompts are effectively non-functional for users with non-standard Documents paths
• Even with standard paths, the prompt injection mechanism appears broken (session tries to read from filesystem rather than receiving injected content)
• This blocks the core value proposition of scheduled tasks — autonomous recurring workflows

Related Issues

• #26254 — SKILL.md files not mounted in container (similar symptom, different context: user/org skills vs scheduled tasks)
• #26998 — Skills not saving/loading on Windows
• #29022 — Schedule skill fails, create_scheduled_task tool not injected

Suggested Fix

1. Inject prompt content directly into session context — don't rely on filesystem mount. The scheduler has the SKILL.md content; pass it to the session the same way system prompts are passed.
2. Respect non-standard Documents paths on Windows — if CLAUDE_CONFIG_DIR or Documents folder is redirected, follow the redirect for both writing and mounting.
3. Propagate working folder setting to VM mount — if a folder is configured in the task Edit form, ensure it's actually mounted (not showing as Scratchpad).

What Should Happen?

Expected Behavior

The session should have the full SKILL.md prompt content available, either:

• Injected into the session context by the scheduler (preferred), OR
• Mounted into the VM filesystem at a path the session can access

Error Messages/Logs

Steps to Reproduce

Steps to Reproduce

1. Create a scheduled task in Cowork (via the create_scheduled_task tool or /schedule skill)
2. Task SKILL.md is saved to E:\Documents\Claude\Scheduled\<task-name>\SKILL.md
3. Task fires on schedule (cron or manual "Run now")
4. Session VM attempts to read SKILL.md — file not found
5. Session falls back to list_scheduled_tasks API to get task description, then improvises

Claude Model

Opus

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

1.1.6679

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

This was in Cowork