claude-code - 💡(How to fix) Fix [BUG] Marketplace plugin sync permanently blocked by PNG compression ratio false positive — stale server-side cache prevents recovery [1 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#50769Fetched 2026-04-20 12:13:32
View on GitHub
Comments
0
Participants
1
Timeline
4
Reactions
0
Author
Participants
Timeline (top)
labeled ×4

Custom marketplace plugin sync fails permanently with "Suspicious compression ratio" error on a PNG file. The error persists indefinitely (3+ days) because:

  1. The server-side cache serves stale plugin content regardless of repo updates
  2. The failed download of ONE plugin blocks sync for ALL plugins in the marketplace
  3. The marketplace cannot be removed (Remove action doesn't persist — marketplace reappears on tab switch/restart)
  4. Even renaming the GitHub repo and creating a fresh repo with the same name doesn't help — the server-side cache is tied to the marketplace registration, not the repo

Error Message

[SkillsPlugin] Failed to download triangility-pptx: Suspicious compression ratio for
"triangility-pptx/assets/logos/Logo_dklgrau.png": 65:1 (max: 50:1)
[SkillsPlugin] Sync complete: 0 downloaded, 0 removed, 0 orphans cleaned

Root Cause

The PNG in question is a logo (1000x309px, RGBA) with large flat-color areas. As a PNG, it compresses very efficiently (1.24 MB raw pixel data → 15 KB file). The ZIP bomb protection appears to compare raw pixel dimensions against file size, not actual ZIP compression ratio. This means any well-compressed PNG with flat colors will trigger the check — even though it poses zero ZIP bomb risk.

The actual ZIP compression ratio (file-in-ZIP vs file-on-disk) is ~1:1 (5.7%), which is completely normal.

Fix Action

Fix / Workaround

  • All 19 plugins in the marketplace are blocked from syncing
  • All team members in the organization are affected (server-side cache is shared)
  • The issue has persisted for 3+ days with no sign of automatic resolution
  • Workaround: created a second marketplace repo with a different name, but existing plugins still reference the old (broken) marketplace

Code Example

[SkillsPlugin] Failed to download triangility-pptx: Suspicious compression ratio for
"triangility-pptx/assets/logos/Logo_dklgrau.png": 65:1 (max: 50:1)
[SkillsPlugin] Sync complete: 0 downloaded, 0 removed, 0 orphans cleaned
RAW_BUFFERClick to expand / collapse

Description

Custom marketplace plugin sync fails permanently with "Suspicious compression ratio" error on a PNG file. The error persists indefinitely (3+ days) because:

  1. The server-side cache serves stale plugin content regardless of repo updates
  2. The failed download of ONE plugin blocks sync for ALL plugins in the marketplace
  3. The marketplace cannot be removed (Remove action doesn't persist — marketplace reappears on tab switch/restart)
  4. Even renaming the GitHub repo and creating a fresh repo with the same name doesn't help — the server-side cache is tied to the marketplace registration, not the repo

Error

[SkillsPlugin] Failed to download triangility-pptx: Suspicious compression ratio for
"triangility-pptx/assets/logos/Logo_dklgrau.png": 65:1 (max: 50:1)
[SkillsPlugin] Sync complete: 0 downloaded, 0 removed, 0 orphans cleaned

Root Cause Analysis

The PNG in question is a logo (1000x309px, RGBA) with large flat-color areas. As a PNG, it compresses very efficiently (1.24 MB raw pixel data → 15 KB file). The ZIP bomb protection appears to compare raw pixel dimensions against file size, not actual ZIP compression ratio. This means any well-compressed PNG with flat colors will trigger the check — even though it poses zero ZIP bomb risk.

The actual ZIP compression ratio (file-in-ZIP vs file-on-disk) is ~1:1 (5.7%), which is completely normal.

Steps to Reproduce

  1. Create a custom marketplace with a plugin containing a PNG logo that has large flat-color areas (e.g., a corporate logo with transparency)
  2. The PNG should be ~1000x300px, RGBA, with solid color fills — results in ~15-30 KB at optimal compression
  3. Push to the marketplace repo
  4. Claude Desktop will fail to sync with "Suspicious compression ratio" error

Attempted Fixes (none worked)

AttemptResult
Re-save PNG with lower compression (compress_level=1, 30 KB, ratio 40:1)Server still serves cached old file (65:1)
Rename the PNG file (Logo_dklgrau.png → logo_dark.png)Server still serves old file under old name
Resize PNG to 500x155 (ratio 17:1)Server cache unchanged
Delete old plugin version directories from repoNo effect
Remove plugin from marketplace.json entirelyServer still tries to download it
Rename GitHub repo + create fresh repo with same name (new repo ID)Server cache tied to marketplace registration, not repo
Create entirely new repo with different nameWorks for NEW plugins, but existing plugins still reference old marketplace
Clear local Claude Desktop caches (Cache/, Session Storage/, blob_storage/)No effect
Restart Claude DesktopNo effect
Remove marketplace via UIDoesn't persist — marketplace reappears on restart

Expected Behavior

  1. PNG ratio check should use actual ZIP compression ratio, not raw pixel data vs file size
  2. Server-side cache should refresh when the source repo is updated (within minutes, not days/never)
  3. One plugin's download failure should not block ALL other plugins in the same marketplace
  4. Marketplace Remove should actually remove the marketplace permanently

Environment

  • Claude Desktop v1.3109.0, macOS
  • Custom marketplace: private GitHub repo in an organization
  • Plugin with ~15 KB PNG logo (1000x309px RGBA)

Impact

  • All 19 plugins in the marketplace are blocked from syncing
  • All team members in the organization are affected (server-side cache is shared)
  • The issue has persisted for 3+ days with no sign of automatic resolution
  • Workaround: created a second marketplace repo with a different name, but existing plugins still reference the old (broken) marketplace

Related Issues

  • #39400 — Marketplace plugins fail to load skills in Cowork (zip upload works)
  • #38429 — RemotePluginManager removes 3rd-party GitHub marketplace plugins on every sync
  • #40600 — Personal marketplace plugin installation lost after restart

extent analysis

TL;DR

The most likely fix for the "Suspicious compression ratio" error is to update the PNG ratio check to use the actual ZIP compression ratio instead of raw pixel data vs file size.

Guidance

  • Verify that the issue is caused by the PNG compression ratio check by testing with different PNG files and compression levels.
  • Consider creating a new plugin with a different name and adding it to the marketplace to see if the issue is specific to the existing plugin or the marketplace as a whole.
  • Since the server-side cache is tied to the marketplace registration, not the repo, try updating the marketplace registration or creating a new marketplace with a different name to see if it resolves the issue.
  • To mitigate the issue, consider using a different image format or resizing the PNG file to reduce the compression ratio.

Example

No code snippet is provided as the issue is related to the PNG compression ratio check and server-side cache, which are not directly related to code.

Notes

The issue is specific to the Claude Desktop v1.3109.0 and the custom marketplace plugin sync. The server-side cache and PNG compression ratio check are the likely causes of the issue. The fix may require updates to the Claude Desktop code or the marketplace plugin sync mechanism.

Recommendation

Apply a workaround by creating a new marketplace with a different name and adding the plugins to it, as this has been shown to work for new plugins. This will allow the team to continue working while a permanent fix is developed.

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