**Title:** [BUG] Cowork/Windows: re-uploading a plugin .zip leaves a stale FUSE size cache — grown scripts are read truncated to the previous version's byte length and fail at runtime

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

On Claude Desktop (Cowork) on Windows, after a plugin is installed from a .zip, re-uploading
the same plugin with an edited script that has grown in size leaves a stale cached file
size. The new file is written to disk in full, but os.path.getsize() and full binary reads
return the previous version's byte length, so the script is read truncated (cut off
mid-content) and fails at runtime with incomplete/invalid code. This is the plugin-zip-update
manifestation of the stale FUSE metadata cache described in #40264.

Environment

• Product: Claude Desktop app (Cowork), manual plugin install via .zip
• OS: Windows 11 (10.0.26200)
• App version: 1.15962.1.0 (MSIX package "Claude"; claude.exe FileVersion 1.15962.1)

Deterministic reproduction

Two zips of the same plugin, differing only in one script (scripts/_repro_sonda.py):

• Version A: the script is 136 bytes (prints REPRO_END_A).
• Version B: the same script is 39,772 bytes (real last line prints REPRO_END_B),

plus one brand-new file scripts/_repro_sonda_nuovo.py (144 bytes) as a control.

1. Upload version A. In Cowork, execute the script:

python _repro_sonda.py -> prints REPRO_END_A, os.path.getsize() -> 136 (correct).

1. Upload version B (same plugin name -> update path). On disk the file is now the 39,772-byte

version B content.

1. Open a new Cowork session and read the same script:

os.path.getsize() and a full binary read both return 136 bytes — the previous
version's size. The bytes returned are the start of version B, cut off mid-line at byte 136
("...# filler line 0002 - se"). The real on-disk file is 39,772 bytes.

Observed

• _repro_sonda.py: real size 39,772 B -> read as 136 B (exactly version A's size). Content

truncated mid-content; the script's real last line (REPRO_END_B) is never reached, so running
it fails / behaves as the old version.

• _repro_sonda_nuovo.py (brand-new file, no previously cached size): read intact at 144 B with

REPRO_END_NEW. -> Only files whose smaller size was previously cached get clamped; new files
are fine.

Crucially, the file is written to disk correctly (the on-disk content is version B). The
truncation is on the read path, caused by a stale cached size that is not invalidated on
re-upload.

Expected

After re-uploading the plugin, getsize/reads return the new size (39,772) and the full content.

Impact

Any plugin script that grows between two uploads is silently read truncated and fails at runtime.
For plugins with executable scripts this means broken skills/agents after an in-place update, with
no error at install time — the failure only shows up when the script is used.

Workaround

Fully remove the plugin and re-add it from scratch restores correct sizes (a plain re-upload
does not). A fresh VM/session alone does not help (the stale entry is inherited).

Related issues (same root cause / family)

• #40264 — Cowork Windows: files truncated on subsequent reads (stale FUSE/VirtioFS metadata size

cache). Same root cause, reached here via the plugin-zip update path; this report adds a
deterministic repro.

• #40231 — "Copy to your skills" silently truncates files that increase in size (closed as not

planned) — almost certainly the same stale-size cache, surfaced via a different install path.

• #14061, #15642, #29074, #18426, #51536 — plugin cache not invalidated on update/reinstall.

What Should Happen?

After re-uploading a plugin whose script has changed size, the file should be read at
its real current size with full content. Specifically: os.path.getsize() and binary
reads should return the new size (39,772 bytes in the repro), and the script should run
correctly — not be read truncated to the previously cached byte length (136 bytes).

The cached file-size metadata must be invalidated when the plugin is re-uploaded, so a
plain re-upload reflects the new content without requiring a full remove + re-add of the
plugin. Re-uploading a plugin should never leave executable scripts silently truncated.

The GitHub issue form splits things into separate fields, so I'll map the rest of ISSUE.md to the likely fields as you go. Typically you'll also hit:

• What happened? / Describe the bug → use the Summary + Observed sections.
• Steps to reproduce → the Deterministic reproduction block (1–3).
• Environment / version → Windows 11 (10.0.26200), app 1.15962.1.0.

Error Messages/Logs

For this bug there's no error at upload/truncation time — it's silent. That's worth stating explicitly in the field (and it's the dangerous part). Paste this:

No error is raised at upload time — the truncation is silent. The failure only surfaces
later, when the truncated script is executed.

Evidence (measured inside Cowork after re-uploading the larger version, in a new session):

  # baseline, after uploading version A (136-byte script):
  $ python _repro_sonda.py
  REPRO_END_A
  os.path.getsize() -> 136

  # after uploading version B (same file, now 39,772 bytes), new session:
  os.path.getsize()      -> 136          # STALE: should be 39,772
  len(open(...,'rb').read()) -> 136      # binary read also clamped to 136
  last 2 bytes           -> b'se' (0x7365)
  content ends mid-line at: "# filler line 0002 - se"   # cut off at byte 136
  actual on-disk file size -> 39,772     # the new content WAS written; only the read is truncated

When this happens to a real script (not a comment-only probe), the truncated file is
syntactically incomplete, so running it fails at runtime, e.g.:
  SyntaxError: unexpected EOF while parsing
or it silently runs the old/partial behavior.

Host-side logs are not useful here: the only on-disk log on Windows
(%LOCALAPPDATA%\Claude\Logs\chrome-native-host.log) is just the browser native-messaging
connector ("Chrome disconnected (EOF received)"). The plugin/Cowork install logs live
inside the Cowork VM and are not exposed on the host.

Steps to Reproduce

Setup: a plugin packaged as a .zip containing a script, e.g. scripts/probe.py. Make two
versions of the same plugin (same plugin name) that differ only in that one script:

• Version A: probe.py is small — 136 bytes, last line prints "REPRO_END_A".
• Version B: probe.py is large — 39,772 bytes, last line prints "REPRO_END_B".

(Version B also adds a brand-new file scripts/probe_new.py, 144 bytes, as a control.)

Steps:

1. Install version A by uploading its .zip in the Claude desktop app (Cowork), Windows.
2. In Cowork, execute the script so its current size gets read/cached:

python probe.py
-> prints "REPRO_END_A"; os.path.getsize(probe.py) -> 136 (correct)

1. Upload version B of the SAME plugin (in-place update). probe.py is now 39,772 bytes;

verify the on-disk file actually contains version B's content.

1. Open a NEW Cowork session and read probe.py again:

os.path.getsize(probe.py) -> 136 (STALE — should be 39,772)
len(open(probe.py,'rb').read()) -> 136 (binary read clamped to 136)
The returned bytes are the START of version B, cut off mid-line at byte 136.
The brand-new file probe_new.py reads intact at its full 144 bytes.

=> A script that existed before and GREW is read truncated to the previously cached size;
a brand-new file is unaffected. The on-disk file is correct (version B); only the read
is truncated, because the cached file size is not invalidated on re-upload.

Notes:

• The effect is intermittent across plain attempts ("often"); the read/execute at the old

size in step 2 + a new session in step 4 makes it reproduce reliably.

• Truncation always clamps to exactly the previous version's byte length

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

Unknown — no known prior working version. I don't have evidence that re-uploading a grown plugin script ever worked correctly on an earlier build, so I can't point to a last-good version.

Claude Code Version

1.15962.1.0

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

_No response_