Cowork scheduled tasks intermittently fail to mount already-connected folders — silent partial mount failures, not just approval-prompt persistence (6 incidents, 6 different folder combos, 2026-08-19 to 2026-08-29)

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?

Across 10 days and at least six independently observed Cowork scheduled/unattended task runs, connected folders that are reliably available in interactive sessions fail to mount for that run. The specific folder(s) dropped differ every single time — there is no one unreliable folder, and no folder that is safe every time.

Evidence table (six incidents, six different folder combinations):

| # | Date | Folders missing that run | Outcome |
|---|---|---|---|
| 1 | 2026-08-19 | engines | Degraded via manual mirror file, no visible failure — first evidence the mounted set is unstable across runs of the same task |
| 2 | 2026-08-25 | engines | Degraded via manual mirror, complete output produced |
| 3 | 2026-08-26 | engines and the Outputs root itself (only one leaf subdirectory several levels under Outputs stayed reachable) | Most severe outcome. The task's guard logic treated the surviving leaf as "proceed" instead of the missing root as a hard stop. A business report was delivered to VP-level recipients with two entire sections silently omitted — no error, no placeholder, just absent, presented as complete. |
| 4 | 2026-08-26 (found 2026-08-27) | scripts and Outputs simultaneously, while engines + two other data folders were present | Halted cleanly (strict guard logic) instead of shipping bad output, but confirms a third non-overlapping combination |
| 5 | 2026-08-28 | scripts and Outputs | Second occurrence of this exact failure for this task (also failed 2026-08-20 the same way) — a monthly deliverable has now failed to produce for the entire month as a direct result |
| 6 | 2026-08-29 | scripts, engines, and a third project folder simultaneously | Halted cleanly, but the first time three folders dropped at once |

Two mitigation hypotheses have been tested against real scheduled runs and falsified:

1. "It's one flaky folder" — ruled out directly by the table above.
2. "Add the folders to the 'Trusted Cowork folders' list so they skip re-approval" — tried after Incident 1. Incidents 2 and 3 (including the worst outcome) happened after this change.

This looks like each new scheduled-session instance draws from an unstable or inconsistently-persisted set of "which of my already-authorized folders actually attach this run," rather than a problem with any single folder's connection.

What Should Happen?

A scheduled task's connected folders should mount consistently and completely on every single run — the same set that is available interactively, every time, not a randomly-varying subset.

At minimum, a scheduled task should be able to positively distinguish, from inside its own session, "the platform granted zero of my folders this run" from "the platform granted some but silently dropped others." Right now both cases present identically as a missing directory, which is exactly how Incident 3 (the silently-incomplete VP-facing report) happened — the task had no way to know part of its expected environment was missing.

Error Messages/Logs

Representative failure traces from three of the six incidents (paths/session IDs anonymized as {SESSION}):

Incident 4/6 style hard-stop (correct defensive behavior, still caused by the platform):
MOUNT_MISSING -- required folders not mounted: scripts Outputs
This is a MOUNT problem, NOT an upstream/CSV/data problem.

Incident 5 (recurring across 2026-08-20 and 2026-08-28, same task):
Missing: Claude\scripts, Claude\Outputs (both topologies checked, neither present)

Incident 3 (the silent-content-loss case) -- no error was thrown at all; the only trace is that the task's own guard treated a surviving leaf path under Outputs as sufficient, so the run "succeeded" while missing content. This is the most concerning case because it produced no error message whatsoever.

Steps to Reproduce

1. In Cowork, connect several folders to a workspace (e.g. 5+ sibling folders under one parent directory) via the normal in-app folder-connection flow.
2. Create multiple scheduled tasks (daily/weekly/monthly cadence) whose prompts reference those connected folders by name, each with its own defensive check for whether its required folders are present at the start of the run.
3. Let the tasks run unattended on their schedule for 1-2 weeks.
4. Compare, run over run and task over task, which of the already-authorized folders are actually present under the session's mount point each time.

Expected: the same folders are mounted every run, matching what was connected.
Actual: a different subset of folders is missing on different runs, with no pattern tied to a specific folder, a specific task, or a specific time of day. Six occurrences observed over 10 days across at least four different scheduled tasks, six different combinations of folders missing each time. Full incident table with dates is in the "What's Wrong" section above; exact session IDs and timestamps for all six incidents are available on request.

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

N/A -- this is Cowork mode in the Claude Desktop app, not the Claude Code CLI. Issue observed continuously through the current app version as of 2026-08-29.

Platform

Other

Operating System

Windows

Terminal/Shell

Non-interactive/CI environment

Additional Information

This looks like the same underlying defect described in two existing open issues on this repo:

• #47180 -- "Cowork scheduled tasks ignore 'Always allow' folder/tool permissions — prompts reappear every run"
• #59302 -- "'Allow for all scheduled runs' folder permission not persisting"

Both describe folder/tool permission state failing to persist across scheduled-task runs. What is reported here is the same class of defect, but manifesting as silent partial mount failures rather than repeated approval prompts -- and it has already produced a materially incomplete business document delivered to end recipients with no visible error (Incident 3), not just an annoyance.

Cost so far: every scheduled task built against these folders now needs its own defensive mount-detection and hard-stop logic to avoid shipping incomplete output -- this has had to be built and maintained across roughly three dozen scheduled tasks in this workspace. That is a substantial, ongoing engineering cost spent working around a platform defect rather than on the actual work the tasks exist to do. One task's monthly deliverable has now failed to produce at all for an entire month as a direct, repeated result of this same issue.

We would like: (1) confirmation this is a known/tracked issue and whether it is the same root cause as #47180/#59302, (2) a way for a task to positively detect partial vs. total mount failure, and (3) a fix or a committed timeline, given the demonstrated business impact. Happy to provide exact session IDs and timestamps for all six incidents on request.