claude-code - 💡(How to fix) Fix [BUG] zlibError decompression failures on session start and command execution [1 comments, 2 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#48503Fetched 2026-04-16 06:58:23
View on GitHub
Comments
1
Participants
2
Timeline
6
Reactions
0
Author
Timeline (top)
labeled ×4commented ×1cross-referenced ×1

Error Message

i am using claude code with litellm and i keep getting decompression error: ZlibError but claude code works but it spams my ui with this error, i can avoid the issue by using alias claude ='claude 2> /dev/null' but i hope there can be a better fix for this. i am using the native build of claude code.. the old js version does not have this issue and if i use claude --debug it does not give my any indication of why the error is happening

Error Messages/Logs

I think that this bug is related to non streaming api calls which claude code does , when one of those fails, we get spammed with zlib error I fixed the core issues in litellm but in the meanwhile if the specific issue you are facing is not impacting your core experience , you can just pipe error output to /dev/null

Code Example

osalloum
on Feb 7 · edited by osalloum
Author
I think that this bug is related to non streaming api calls which claude code does , when one of those fails, we get spammed with zlib error
Claude code does a lot of misc calls to generate custom titles , check token sizes, etc

I fixed the core issues in litellm but in the meanwhile if the specific issue you are facing is not impacting your core experience , you can just pipe error output to /dev/null


claude 2> /dev/null


ernestkoe
on Mar 7
Claude and I have a theory on what's happening:

HTTP MCP transport is sending compressed gzip that the client isn't handling.

The SDK uses fetch directly — it doesn't set Accept-Encoding, but Bun's fetch might auto-negotiate gzip. The issue is likely that the SSE event stream is being compressed by the server but the SDK's SSE parser can't handle it. The fix is to tell the server not to compress by adding Accept-Encoding: identity to the request headers:
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?

Image Bug Description i am using claude code with litellm and i keep getting decompression error: ZlibError but claude code works but it spams my ui with this error, i can avoid the issue by using alias claude ='claude 2> /dev/null' but i hope there can be a better fix for this. i am using the native build of claude code.. the old js version does not have this issue and if i use claude --debug it does not give my any indication of why the error is happening

Environment Info

Platform: darwin Terminal: WarpTerminal Version: 2.1.107

Feedback ID: ebf2a7c7-86d6-4c89-bce2-dc852fc25a94 https://github.com/anthropics/claude-code/issues/20199 https://github.com/anthropics/claude-code/issues/18302

What Should Happen?

no ZlibError spam in terminal/ghostty

Error Messages/Logs

osalloum
on Feb 7 · edited by osalloum
Author
I think that this bug is related to non streaming api calls which claude code does , when one of those fails, we get spammed with zlib error
Claude code does a lot of misc calls to generate custom titles , check token sizes, etc

I fixed the core issues in litellm but in the meanwhile if the specific issue you are facing is not impacting your core experience , you can just pipe error output to /dev/null


claude 2> /dev/null


ernestkoe
on Mar 7
Claude and I have a theory on what's happening:

HTTP MCP transport is sending compressed gzip that the client isn't handling.

The SDK uses fetch directly — it doesn't set Accept-Encoding, but Bun's fetch might auto-negotiate gzip. The issue is likely that the SSE event stream is being compressed by the server but the SDK's SSE parser can't handle it. The fix is to tell the server not to compress by adding Accept-Encoding: identity to the request headers:

Steps to Reproduce

just start claude in terminal (any terminal). Wait.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

No response

Claude Code Version

2.1.105

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

No response

extent analysis

TL;DR

The most likely fix is to modify the request headers to prevent compression by adding Accept-Encoding: identity to handle the SSE event stream correctly.

Guidance

  • The issue is likely caused by the server compressing the SSE event stream, which the SDK's parser cannot handle.
  • To verify, check the request headers and see if Accept-Encoding is set to gzip or another compression algorithm.
  • To mitigate, try adding Accept-Encoding: identity to the request headers to prevent compression.
  • Consider updating the SDK to handle compressed SSE event streams or modifying the server to not compress the stream.

Example

No code snippet is provided as the issue is related to the interaction between the client and server, and the exact implementation details are not specified.

Notes

The provided information suggests that the issue is related to the compression of the SSE event stream, but the exact cause and solution may depend on the specific implementation of the SDK and server.

Recommendation

Apply workaround: Add Accept-Encoding: identity to the request headers to prevent compression, as this is a targeted solution to the identified issue.

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

claude-code - 💡(How to fix) Fix [BUG] zlibError decompression failures on session start and command execution [1 comments, 2 participants]