claude-code - 💡(How to fix) Fix [BUG] ZstdDecompressionError printed to TUI when ztsd compressed connection is disconnected. [2 comments, 3 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#48662Fetched 2026-04-16 06:54:21
View on GitHub
Comments
2
Participants
3
Timeline
7
Reactions
1
Timeline (top)
labeled ×4commented ×2closed ×1

Error Message

[DEBUG] MCP server "plugin:<RedactedPlugin>:data-concierge": Connection error: SSE stream disconnected: Error: ZstdDecompressionError fetching "https://ddr-<RedactedPlugin>mcp.dev.sp.<RedactedDomain>.com/mcp"

★ Insight ───────────────────────────────────── The <RedactedPlugin> MCP server uses Server-Sent Events (SSE) for its transport. The SSE HTTP response from ddr-<RedactedPlugin>mcp.dev.sp.<RedactedDomain>.com is served with Content-Encoding: zstd. Node.js's fetch API (bundled in the claude binary) decompresses it transparently — but when the long-lived SSE connection drops mid-stream, it's holding a partial Zstd frame that can't be completed, hence ZstdDecompressionError. This is a server-side issue: the <RedactedPlugin> MCP server should either use plain/gzip encoding for SSE, or the client should handle partial-frame disconnects gracefully. ─────────────────────────────────────────────────

The culprit is the <RedactedPlugin> MCP server at ddr-<RedactedPlugin>mcp.dev.sp.<RedactedDomain>.com. Its SSE stream uses Zstd compression, and when the connection drops (which SSE connections do periodically), the partial compressed frame triggers the error.

This is not something you can fix locally — it's a server-side or Claude Code client-side issue. Options:

  1. Short term: Disable the <RedactedPlugin> MCP server to stop the errors:

In /mcp, disable plugin:<RedactedPlugin>:data-concierge

  1. Report it: File at https://github.com/anthropics/claude-code/issues — Claude Code's SSE client should catch ZstdDecompressionError on disconnect and treat it as a clean reconnect rather than a visible error.

Code Example

[DEBUG] MCP server "plugin:<RedactedPlugin>:data-concierge": Connection error: SSE stream disconnected:
  Error: ZstdDecompressionError fetching "https://ddr-<RedactedPlugin>mcp.dev.sp.<RedactedDomain>.com/mcp"

Insight ─────────────────────────────────────
  The <RedactedPlugin> MCP server uses Server-Sent Events (SSE) for its transport. The SSE HTTP response from ddr-<RedactedPlugin>mcp.dev.sp.<RedactedDomain>.com is served with Content-Encoding: zstd.
  Node.js's fetch API (bundled in the claude binary) decompresses it transparently — but when the long-lived SSE connection drops mid-stream, it's holding a partial Zstd frame that can't be
   completed, hence ZstdDecompressionError. This is a server-side issue: the <RedactedPlugin> MCP server should either use plain/gzip encoding for SSE, or the client should handle
  partial-frame disconnects gracefully.
  ─────────────────────────────────────────────────

  The culprit is the <RedactedPlugin> MCP server at ddr-<RedactedPlugin>mcp.dev.sp.<RedactedDomain>.com. Its SSE stream uses Zstd compression, and when the connection drops (which SSE connections do
  periodically), the partial compressed frame triggers the error.

  This is not something you can fix locally — it's a server-side or Claude Code client-side issue. Options:

  1. Short term: Disable the <RedactedPlugin> MCP server to stop the errors:
  # In /mcp, disable plugin:<RedactedPlugin>:data-concierge
  2. Report it: File at https://github.com/anthropics/claude-code/issues — Claude Code's SSE client should catch ZstdDecompressionError on disconnect and treat it as a clean reconnect
  rather than a visible error.

---

See above.
RAW_BUFFERClick to expand / collapse

Preflight Checklist

  • I have searched existing issues and this hasn't been reported yet
  • This is a single bug report (please file separate reports for different bugs)
  • I am using the latest version of Claude Code

What's Wrong?

While Claude is operating or during background tasks, if an MCP server is using ZTSD compression and disconnects mid stream, claude fails and prints the error message Decompression error: ZstdDecompressionError to the TUI breaking the user interface.

Debugging this with claude, the result is:

[DEBUG] MCP server "plugin:<RedactedPlugin>:data-concierge": Connection error: SSE stream disconnected:
  Error: ZstdDecompressionError fetching "https://ddr-<RedactedPlugin>mcp.dev.sp.<RedactedDomain>.com/mcp"

  ★ Insight ─────────────────────────────────────
  The <RedactedPlugin> MCP server uses Server-Sent Events (SSE) for its transport. The SSE HTTP response from ddr-<RedactedPlugin>mcp.dev.sp.<RedactedDomain>.com is served with Content-Encoding: zstd.
  Node.js's fetch API (bundled in the claude binary) decompresses it transparently — but when the long-lived SSE connection drops mid-stream, it's holding a partial Zstd frame that can't be
   completed, hence ZstdDecompressionError. This is a server-side issue: the <RedactedPlugin> MCP server should either use plain/gzip encoding for SSE, or the client should handle
  partial-frame disconnects gracefully.
  ─────────────────────────────────────────────────

  The culprit is the <RedactedPlugin> MCP server at ddr-<RedactedPlugin>mcp.dev.sp.<RedactedDomain>.com. Its SSE stream uses Zstd compression, and when the connection drops (which SSE connections do
  periodically), the partial compressed frame triggers the error.

  This is not something you can fix locally — it's a server-side or Claude Code client-side issue. Options:

  1. Short term: Disable the <RedactedPlugin> MCP server to stop the errors:
  # In /mcp, disable plugin:<RedactedPlugin>:data-concierge
  2. Report it: File at https://github.com/anthropics/claude-code/issues — Claude Code's SSE client should catch ZstdDecompressionError on disconnect and treat it as a clean reconnect
  rather than a visible error.

What Should Happen?

The errors should be handled and not printed to the TUI

Error Messages/Logs

See above.

Steps to Reproduce

Create an MCP server or plugin that uses ztsd compression. Disconnect it while claude is trying to read from it.

Claude Model

Sonnet (default)

Is this a regression?

I don't know

Last Working Version

No response

Claude Code Version

2.1.107

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

iTerm2

Additional Information

<img width="1520" height="198" alt="Image" src="https://github.com/user-attachments/assets/fbf0b75c-3b27-47d0-bf93-3924bdcf7ecb" />

Error message can be seen here.

extent analysis

TL;DR

Disable the problematic MCP server or report the issue to improve Claude Code's SSE client to handle ZstdDecompressionError on disconnect.

Guidance

  • Identify and disable the MCP server causing the issue, specifically the one using Zstd compression, by disabling plugin:<RedactedPlugin>:data-concierge in /mcp.
  • Report the issue to the Claude Code developers to request an improvement in handling ZstdDecompressionError on disconnect, allowing for a clean reconnect instead of displaying an error.
  • Verify the issue by creating an MCP server or plugin with Zstd compression and disconnecting it while Claude is reading from it to see if the error persists.
  • Consider using plain or gzip encoding for SSE streams as an alternative to Zstd compression to avoid this issue.

Notes

The provided solution is a temporary workaround, and a long-term fix would require changes to the Claude Code client or the MCP server to handle partial-frame disconnects more robustly.

Recommendation

Apply workaround: Disable the problematic MCP server until a fix is available, as this is a server-side or client-side issue that cannot be resolved locally.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING