[BUG] Sandbox bash mount returns truncated/partial file reads (Cowork mode)

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?

BUG: Sandbox bash mount returns truncated/partial file reads (Cowork mode)

Environment: Claude in Cowork mode (desktop app, research preview). Linux sandbox
exposed via the bash tool, with a connected host folder mounted into the sandbox.

Summary: Reading files through the bash sandbox (cat/wc/cp/python open()) intermittently
returns TRUNCATED content — the file appears shorter than it is, cut off mid-line —
while the native Read/Write/Edit file tools read the same files fully and correctly.
The truncation is non-deterministic: the same file sometimes reads fully, sometimes not.

Evidence (real session, 2026-07-06):

• A ~500-line Python file (~17.3 KB) passed python -m py_compile once (read fully),

but a subsequent cp of the same file to /tmp produced a 423-line copy missing the
tail (wc -l = 423). A function defined past the cut point then raised NameError at
runtime when the module was exec'd.

• Two other files (~7.4 KB and ~17.5 KB) failed py_compile with syntax errors

("'[' was never closed" / "'(' was never closed") located EXACTLY at the truncation
boundary (mid-statement). The Read tool showed both files complete and valid past
those lines.

• cp to /tmp did NOT help — the copy was also truncated — so the truncation is at the

mount/read layer, not an output display cap.

Reproduction (approx): In the Cowork Linux sandbox, repeatedly read a moderately large
(>~10 KB) text file in the mounted folder via cat/wc/cp/python. Observe intermittent
truncation (boundary seen around ~10.5 KB / ~260–420 lines, inconsistent).

Impact: In-sandbox verification (compiling/running/testing code) is unreliable — phantom
syntax errors and NameErrors at truncation boundaries. A less cautious workflow could
"fix" nonexistent errors and corrupt real code. Workaround: verify via the Read tool
(reliable) and run logic in self-contained scripts that don't import truncated modules.

Note: Read/Write/Edit file tools are NOT affected — they read the true, full file. The
bug is specific to the bash/sandbox mount's view of mounted-folder files.

Likely root cause: the FUSE mount that bridges the host folder into the coworkd Linux
container appears to return truncated/partial reads (intermittently) for larger files.
The host-side file tools (Read/Write/Edit) read the same paths completely, while bash —
which goes through the container's FUSE mount — gets short reads. Suspect unhandled
partial reads / offset or caching bug in the FUSE bridge, not WSL (this host is Windows
but the sandbox is a native Ubuntu container, not WSL).

What Should Happen?

Reading a file through the bash sandbox should return the file's complete, current
contents — byte-for-byte identical to what the native Read/Write/Edit file tools
return for the same path — every time, deterministically.

Specifically:

• cat / wc / cp / python open() on a mounted-folder file should read the entire

file, never a partial/truncated copy cut off mid-line.

• Repeated reads of the same unchanged file should be consistent (no run-to-run

variation between full and truncated).

• File size should be independent of the read method: a file that is N bytes /

M lines on disk should read as N bytes / M lines via bash, matching the file tools.

Net: the bash-sandbox view and the file-tool view of the same mounted files should
always agree, so in-sandbox compiling/running/testing is trustworthy.

Error Messages/Logs

# 1) py_compile reports a syntax error at the truncation boundary — the file is cut
#    mid-statement. The Read tool showed these files complete and valid past these lines.

  File "models.py", line 178
    notes: Optional[str
                   ^
SyntaxError: '[' was never closed
FAIL: models.py

  File "routers/pathfind.py", line 402
    hops.append(HopResult(
                         ^
SyntaxError: '(' was never closed
FAIL: routers/pathfind.py


# 2) cp-to-/tmp then compile — the COPY is also truncated (177 / 403 lines; real files
#    are longer), proving the truncation is at the mount/read layer, not a display cap.

tmp sizes:
  177 /tmp/m.py
  403 /tmp/p.py


# 3) A ~500-line file (~17.3 KB) copied as only 423 lines — the tail (incl. the
#    _parse_iface_line definition) is missing from the copy...

copied bytes: 17300, lines: 423


# 4) ...so exec'ing that truncated module raises NameError for a function that IS
#    defined in the real file, just past the truncation point:

Traceback (most recent call last):
  File "<stdin>", line 6, in <module>
  File ".../backend/parsers/cisco.py", line 300, in parse_cisco_ios
    _parse_iface_line(line, current_iface, interfaces)
NameError: name '_parse_iface_line' is not defined. Did you mean: '_parse_std_acl_line'?


# 5) Inconsistency: the SAME file (cisco.py, 17.3 KB) read FULLY under py_compile on an
#    earlier call in the same session (passed, "OK: parsers/cisco.py") but truncated on
#    subsequent cp/exec — i.e. non-deterministic run-to-run.

Steps to Reproduce

Environment: Claude in Cowork mode (desktop app), with a connected/mounted folder
available to the bash sandbox tool.

Note: the bug is intermittent and appears on larger files (truncation boundary observed
around ~10.5 KB / a few hundred lines). These steps make it obvious with a sentinel and
by repeating the read.

1. Create a known-good test file in the mounted folder, WRITTEN VIA THE FILE-WRITE TOOL

(or on the host) — not via bash — so the on-disk file is guaranteed complete. Make it
comfortably larger than the truncation threshold (~20 KB) and give it a unique LAST
line as a sentinel. Minimal generator content to write to repro.txt:

line 0001 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
line 0002 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
... (600 numbered lines, ~40 chars each ≈ 24 KB) ...
line 0600 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
SENTINEL-LAST-LINE-DO-NOT-TRUNCATE

(Any existing source file > ~15 KB works too; the sentinel just makes the check crisp.)

1. Confirm the file is complete via the Read FILE TOOL (not bash): it should show all

601 lines ending in SENTINEL-LAST-LINE-DO-NOT-TRUNCATE.

1. In the BASH SANDBOX, read the same file several times in a row and compare to the

known size:

wc -c repro.txt # expect ~24000
wc -l repro.txt # expect 601
tail -n 1 repro.txt # expect: SENTINEL-LAST-LINE-DO-NOT-TRUNCATE
cp repro.txt /tmp/c.txt && wc -l /tmp/c.txt # copy should also be 601 lines

Run this block 3–5 times.

1. OBSERVE the bug: on some runs, wc -c / wc -l report FEWER bytes/lines than were

written; tail -n 1 shows a mid-file line (e.g. "line 0423 ...") instead of the
sentinel; and the /tmp copy is ALSO short. The same unchanged file may read fully on
one call and truncated on the next (non-deterministic).

1. Cross-check: read the file again via the Read FILE TOOL — it returns the full 601

lines including the sentinel. => bash-sandbox view is truncated while the file-tool
view is complete, for the identical path.

Minimal real-world trigger seen in-session: a ~17.3 KB, ~500-line Python file compiled
fine once via python -m py_compile (full read),

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

Claude Code (sandbox runtime): 2.1.197 node: v22.22.3 npm: 10.9.8 Cowork desktop app version: <check App → About; separate from the above> Bug layer: the bash-sandbox mount's file reads (Claude Code side).

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

Operating System:
Host OS: Windows <your version — e.g. Windows 11 23H2>
Sandbox: Ubuntu 22.04.5 LTS (kernel 6.8.0-124-generic), coworkd-managed container — NOT WSL
Connected folder mount: FUSE (type fuse, allow_other) bridging the Windows host folder into the Linux container.

Terminal/Shell:
N/A — not a terminal-based tool. Cowork is a GUI desktop app on Windows; there is no
interactive terminal/shell the user types into.

The shell where the bug manifests is the sandbox's programmatic shell: GNU bash 5.1.16
(x86_64), invoked non-interactively as bash -c by the agent's tool inside the Ubuntu
22.04 coworkd container (no TTY / no terminal emulator).

Note: the shell is not the cause — reads via bash go through the FUSE mount bridging the
Windows host folder into the container, and that FUSE layer is where the truncation
occurs (see root-cause note). Any process reading through that mount (cat, cp, python,
bash builtins) sees the same truncation.