[BUG] Shell snapshot silently truncated at ~7.2KB on Windows (Desktop) - every Bash call fails with unexpected EOF

Status Open

Reported on v2.1.247

Maintainer reply None cached

Activity 3 comments · opened Aug 28, 2026

Summary

On Windows (Claude Desktop), the Bash tool's shell snapshot file is silently truncated at ~7.2 KB, cutting the export PATH='...' line mid-entry. The unclosed single quote makes every subsequent Bash invocation fail with:

/usr/bin/bash: -c: line 75: unexpected EOF while looking for matching `''

This looks like the same symptom family as #3577 / #19053, but the cause here is measurable truncation, not escaping.

Environment

Claude Desktop 1.40609.0.0 (Microsoft Store package), local agent mode
Embedded Claude Code: strings in app.asar indicate 2.1.247
Windows 11 Home 10.0.26200, Git Bash (Git for Windows)
~35 enabled plugins (official marketplace + one custom marketplace)

Evidence

Every snapshot in ~/.claude/shell-snapshots/ ends at 7187–7195 bytes, always mid-PATH, no closing quote, no trailing newline:

``...local-agent-mode-sessions/e67ba6 <-- EOF, quote never closed``

The PATH is long because each enabled plugin contributes an entry like

.../AppData/Roaming/Claude/local-agent-mode-sessions/<uuid>/plugin_<ULID>/bin
(~105 chars each). With ~35 plugins the full snapshot would be roughly 9–10 KB.

Truncation size + wrapper overhead ≈ 8191, which is the Windows cmd.exe

command-line length limit — suggesting the snapshot content passes through a
command line (or cmd-expanded env var) somewhere in the writer and is silently
clipped at that boundary.

Repairing the file on disk (closing the quote at the last complete PATH entry)

does not recover the running session — the Bash tool keeps failing with the
same error, and deleting the snapshot makes commands silently no-op (exit 0,
no output, no side effects). So the truncated content appears to be captured
in memory at write time; the file is only a byproduct. This also means
SessionStart/PreToolUse repair hooks cannot help.

Repro

Windows + Claude Desktop, enable enough plugins that

(base PATH + N × ~105 chars) pushes the snapshot body past ~7.2 KB
(~30–40 plugins in our case).

Start any session, run any Bash command.
Observe unexpected EOF while looking for matching quote, exit code 2, on

every Bash call for the whole session. Newest snapshot file ends mid-PATH.

Impact

Bash tool is completely unusable in Desktop sessions once the plugin count
crosses the threshold. Disabling plugins "fixes" it, which is how we confirmed
the length dependency — but that is not a viable workaround for users who need
their plugins.

Expected

Snapshot writer should not depend on command-line length (write via stdin/file),
or should at minimum fail loudly instead of producing a truncated script that
poisons every subsequent Bash call.

View original on GitHub ↗

3 Comments

qadsawee79 · 24 days ago

Confirming on Claude Code 2.1.222 (Claude Desktop, Windows 11 build 10.0.26200, Git for Windows 2.55.0, bash 5.3.15). Every Bash call fails, even echo hi, for the whole session: -c: line 84: unexpected EOF while looking for matching '. The line number was 75 in the original report and 86 in #83243, so it varies with wrapper length.

Extra data points:

41 snapshots in shell-snapshots/. 33 have an odd number of single quotes, cut off mid-export PATH='...'. Sizes range from 5,753 to 7,195 bytes. The newest is 7,192 bytes, and its PATH line starts at byte 1,634 and is cut after 103 entries (26 plugin cache dirs from 11 marketplaces, plus 5 local-agent-mode-sessions dirs).
Independently confirms point 4: closing the quote in the newest snapshot on disk did not recover the running session.
Raw bash.exe -c works, including quotes. Both PreToolUse Bash hooks behave correctly when I feed them sample payloads by hand. So it isn't the shell or the hooks.
New observation: snapshots from days when Bash worked (2026-09-14, -19, -20) were the same size and cut off in the same way. So the file on disk isn't what fails. What varies is the PATH the app hands the session at launch, which supports the in-memory theory.
Workaround: the PowerShell tool is unaffected.

SATSIGO40 · 22 days ago

Adding a data point from another Windows Desktop machine that I think narrows this down: the snapshot file on disk is intact, and the same machine's standalone CLI runs Bash fine at the same moment Desktop fails.

Environment

Windows 11 Pro 10.0.26200, Git for Windows (bash 5.2.37)
Claude Desktop (Microsoft Store package): broke on 2026-09-16, right after the package updated to 2.110.0.0; still broken after it updated to 2.7032.0.0 on 2026-09-23
Standalone CLI: claude v2.1.207 (%USERPROFILE%\.local\bin\claude.exe)
The Windows username contains non-ASCII (Japanese) characters

Symptom. Since 2026-09-16 every Bash call in Desktop fails, including echo test:

/usr/bin/bash: -c: line 83: unexpected EOF while looking for matching `''

Before 09-16, Bash worked for most commands, but some longer inline commands already failed with this same error (line 78–82). After the Desktop update, even a one-word command fails. That pattern fits the length-limit theory above, with the wrapper growing in the update.

What's different from the original report

The snapshot file is not truncated. The newest file in ~/.claude/shell-snapshots/ is 44 lines / 3,946 bytes, has an even number of single quotes (6), and has the same SHA-256 as a snapshot from 2026-09-13. The failing line (83) is past the end of the 44-line file, so the break is in the command string the tool builds, not in the file. This matches the in-memory point in the comment above.
No plugin bin dirs on PATH. PATH is 1,665 chars / 41 entries, with 0 plugin entries. The snapshot's export PATH= line is 2,158 chars. So this reproduces without the plugin-PATH growth.
Standalone CLI works, Desktop fails, on the same machine, user, cwd and ~/.claude. At 2026-09-23 22:21 JST, claude v2.1.207 launched normally (all customizations loaded) from the same directory ran Bash(echo test) and printed test. In the same minute, the Desktop session failed with the error above. Because the CLI works with customizations loaded, plugins, hooks and MCP are not the trigger here.
A Windows reboot does not fix it.
Git Bash itself is fine. Running "C:\Program Files\Git\bin\bash.exe" -c '...' directly from PowerShell works, including cd into the non-ASCII home path.

Workaround: the PowerShell tool is unaffected; we have run everything through it since 2026-09-16.

Note: the CLI auto-updated to 2.1.280 right after this test. I have not re-run the test on 2.1.280.

qadsawee79 · 22 days ago

Confirming the pattern from the comment above (SATSIGO40, 2026-09-23): on my own machine, in the same minute, from the same ~/.claude config and cwd:

Standalone CLI (claude.exe v2.1.278, headless -p): Bash(echo hi) ran clean, exit 0.
This same session's Desktop app Bash tool: still fails with the identical -c: line 84: unexpected EOF while looking for matching '.

So on my machine too, the standalone CLI and Desktop diverge with everything else held constant. My earlier comment's PATH/plugin-count/snapshot-truncation theory may still explain why my snapshot itself is truncated, but it isn't the whole story — the standalone CLI reads the same ~/.claude (same plugins, same PATH-lengthening entries would apply to it too) and still runs Bash fine. So the fault has to be in something Desktop does differently when building/executing the Bash command, not just accumulated PATH length.