Scheduled Tasks: bash sandbox mount failing intermittently since 2026-09-08 (Windows)

Environment: Windows 11 Pro, Claude Desktop app, Scheduled Tasks feature (unattended tasks running in a sandboxed session, using what appears to be a device_bash / mcp__workspace__bash tool backed by a Plan9/virtiofs-style mount).

Summary: Since 2026-09-08, scheduled/unattended tasks on this machine have repeatedly been unable to reach their bash sandbox tool. The failure is at the mount level, not the command level — no shell, no file listing, no hashing, and no live clock available through that route for the whole affected run.

Observed error signatures (worded differently run to run — likely the same underlying issue, described inconsistently because there's no stable diagnostic surfaced to the task):

• "Bash down at infra level (Plan9 mount failure, 3x identical RPC errors)"
• "device_bash failed outright at session start: 'no Plan9 drive shares mounted under /mnt/.virtiofs-root/shared'"
• Later runs called it a "virtiofs outage," and the most recent runs call it a "Windows-update mount failure"

Frequency: At least 8 distinct occurrences logged across separate scheduled-task runs between 2026-09-08 and 2026-09-15 (most recent today). Multiple different scheduled tasks failed on the same nights, which points to a shared underlying resource (the bash sandbox mount) rather than a per-task problem.

Impact: Every affected run had a working fallback (a local file-system/process-execution tool instead of the bash sandbox), so nothing was lost, but any task that assumed bash as its default/primary tool failed or had to improvise a workaround live, each time, because no fallback was designed in ahead of time.

What I've ruled out:

• WSL is not installed on this machine, so this isn't a local WSL virtiofs/9p problem.
• The failure is specific to the sandboxed bash tool used by unattended/scheduled-task sessions — an interactive Claude Code session on the same machine, around the same time, used its own separate Bash tool (Git Bash/MSYS2) with no issues at all.

Request: Please look into the mount reliability for the sandboxed bash tool used by Scheduled Tasks / unattended execution, and consider surfacing a clearer, more specific error when this mount is down, so a task can detect and route around it immediately instead of guessing at root cause each time (three different descriptions of what looks like one issue, across different runs).

Happy to provide more detail/logs if useful.