[BUG] Cowork scheduled task reads stale filesystem snapshot between invocations (Windows)

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?

Environment - Platform: Windows 11 Pro (26200), bash (Git Bash) - Feature: Cowork scheduled task, Legacy Model - Related: #47899 (same silent-failure class, different symptom — that issue is task never executes; here the task does execute but on a frozen filesystem view) Summary A Cowork scheduled task polls an inbox file on the Windows host every 5 minutes. After the task's last successful run, the sandbox's filesystem view of that file froze at the post-success state. Every subsequent scheduled invocation (9 in a row across ~50 minutes) read the same stale view and short-circuited. Interactive replies to the task thread saw the live filesystem; only the scheduled-polling path was affected. Setup - Inbox file: C:\Users\erinm\Desktop\Pantone Matcher\_pending_swatch_job.txt - Upstream: an InDesign ExtendScript writes a CSV filename into the inbox. - Task reads the inbox → processes the job → clears the inbox to 0 bytes as its last step (by design). - Last successful run: Apr 17 15:33. Inbox correctly cleared to 0 bytes at that time.

What Should Happen?

So this task should pick up the signal file, navigate to the appropriate tabs in Chrome, performs conversions then writes the results to an excel spreadsheet. but the signal file is never getting picked up since it's reading zero bytes.

Error Messages/Logs

$ ls -la "C:\Users\erinm\Desktop\Pantone Matcher\_pending_swatch_job.txt"
-rwx------ 1 great-modest-heisenberg great-modest-heisenberg 0 Apr 17 15:33
C:\Users\erinm\Desktop\Pantone Matcher\_pending_swatch_job.txt

Steps to Reproduce

Given you've already got the "Create new issue" modal open and Bug Report selected, I recommend filing a new issue rather than commenting on #47899. Different symptom, different probable root cause, cleaner triage. Cross-reference #47899 in the body as related.

Setup - Inbox file: C:\Users\erinm\Desktop\Pantone Matcher\_pending_swatch_job.txt - Upstream: an InDesign ExtendScript writes a CSV filename into the inbox. - Task reads the inbox → processes the job → clears the inbox to 0 bytes as its last step (by design). - Last successful run: Apr 17 15:33. Inbox correctly cleared to 0 bytes at that time. Reproduction timeline (Apr 20) - 09:41 — upstream script writes a new job to the inbox (file now 84 bytes, mtime Apr 20 09:41). - 09:43, 09:48, 09:53, 09:58, 10:03, 10:08 — scheduled runs all report inbox as 0 bytes, mtime Apr 17 15:33. - 10:10 — upstream script writes again (file now 157 bytes, mtime Apr 20 10:10). - 10:13, 10:18, 10:23, 10:28, 10:33, 10:38, 10:43 — scheduled runs still report 0 bytes, Apr 17 15:33. Evidence from within the scheduled-task sandbox `` $ ls -la "C:\Users\erinm\Desktop\Pantone Matcher\_pending_swatch_job.txt" -rwx------ 1 great-modest-heisenberg great-modest-heisenberg 0 Apr 17 15:33 C:\Users\erinm\Desktop\Pantone Matcher\_pending_swatch_job.txt `` Actual file on the Windows host at the same moment: 157 bytes, mtime Apr 20 10:10:02.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

Claude Code 2.1.111

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

Workaround that restored a fresh view Replying a message interactively to the task thread caused the next query to see the live filesystem (both new CSVs visible with correct mtimes). The next scheduled firing after that also succeeded. So the stale state is invalidated by interactive replies but not by cron-triggered invocations. Hypothesis The Linux-side bind-mount (the sandbox identifies as great-modest-heisenberg) or its inode cache appears to be established once and not refreshed between scheduled invocations. Interactive sessions seem to take a different code path that does invalidate. The "Apr 17 15:33" mtime matches the exact moment of the last successful run, suggesting the view froze at that success transition. Impact Classic silent failure: Runs list is green, no errors surfaced, no output to downstream consumers. Only noticed after running the upstream job twice with zero downstream effect. Same failure signature family as #47899.