jcodemunch-mcp can't be installed or run

[youvegotmoxie]

This was working until today. Both pip and uvx can't find the library now

❯ uvx jcodemunch-mcp config --check
  × No solution found when resolving tool dependencies:
  ╰─▶ Because there are no versions of jcodemunch-mcp and you require jcodemunch-mcp, we can conclude that your requirements are unsatisfiable.

❯ python -m pip install jcodemunch-mcp==1.108.20
ERROR: Could not find a version that satisfies the requirement jcodemunch-mcp==1.108.20 (from versions: none)

❯ python -m pip install jcodemunch-mcp
ERROR: Could not find a version that satisfies the requirement jcodemunch-mcp (from versions: none)

[ClawzLifts]

Same here

uvx jcodemunch-mcp
× No solution found when resolving tool dependencies:
╰─▶ Because there are no versions of jcodemunch-mcp and you require jcodemunch-mcp, we can conclude that your
requirements are unsatisfiable.

[MariusAdrian88]

From pypi.org:

This project has been quarantined.

PyPI Admins need to review this project before it can be restored. While in quarantine, the project is not installable by clients, and cannot be being modified by its maintainers.

Read more in the [project in quarantine](https://pypi.org/help/#project_in_quarantine) help article.

https://pypi.org/project/jcodemunch-mcp/1.108.20/

@jgravelle is this related to the NPM problems?

Scanner: https://github.com/Intrudify/mini-shai-hulud-scanner
It can be flagged by the antivirus since it has the problem's details (bad SHA-256 hashes).

[youvegotmoxie]

It would be nice if there wasn't lag between it being quarantined and the banner being displayed 🙃

[jgravelle]

Confirmed: jcodemunch-mcp is sitting in PyPI's automated quarantine (pypi:project-status: quarantined in the simple-index meta). Quarantine blocks installs for every version, not just the latest, until PyPI Admins review.

Not related to the npm Shai-Hulud worm. jcodemunch-mcp is pure-Python, no setup.py, no postinstall hooks, no network egress at install time. Reasonable best-guess at the trigger: v1.108.20 landed a _should_index_file helper that does secret-detection and symlink-walk filtering during file discovery (legitimate, for ignoring credentials/binaries when indexing your own repos). Automated PyPI scanners can pattern-match the "secret detection" + .git-walking signature and false-positive.

Workaround while PyPI reviews. Install from the GitHub release directly:

pip install https://github.com/jgravelle/jcodemunch-mcp/releases/download/v1.108.19/jcodemunch_mcp-1.108.19-py3-none-any.whl

Or for uvx:

uvx --from https://github.com/jgravelle/jcodemunch-mcp/releases/download/v1.108.19/jcodemunch_mcp-1.108.19-py3-none-any.whl jcodemunch-mcp

Filing the unquarantine request with PyPI Admins now. Will update this issue when status flips.

@MariusAdrian88, thanks for the fast diagnosis and the mini-shai-hulud-scanner pointer. That pattern (scanner artifact tripping AV on the scanner itself) is real but isn't this case; our wheel doesn't embed the IOC hashes. Different cause, similar shape.

@ClawzLifts, @youvegotmoxie, sorry for the disruption. The banner-vs-meta lag is on PyPI's side: the simple-index <meta> flips immediately, the project-page banner renders after a separate worker pass.

-jjg

[jgravelle]

Update: v1.108.20 wheel + sdist are now attached to the GitHub release as a parallel install path while PyPI reviews. The latest release is fully usable off-PyPI:

pip install https://github.com/jgravelle/jcodemunch-mcp/releases/download/v1.108.20/jcodemunch_mcp-1.108.20-py3-none-any.whl

uvx:

uvx --from https://github.com/jgravelle/jcodemunch-mcp/releases/download/v1.108.20/jcodemunch_mcp-1.108.20-py3-none-any.whl jcodemunch-mcp

Also confirmed the sibling packages are unaffected. jdocmunch-mcp and jdatamunch-mcp are both pypi:project-status: active; this is isolated to jcodemunch-mcp.

-jjg

[jgravelle]

Timeline update: PSF PyPI Security (Mike Fiedler) replied to confirm receipt. New-issue response is delayed due to conference travel; full-time responses resume May 26.

That puts the realistic unquarantine window at late next week. The GitHub-release install paths above (pip install <release-url> and uvx --from <release-url>) are the supported channel for v1.108.19 and v1.108.20 in the meantime, and they're as functional as a PyPI install. Both wheels are attached to their respective GitHub releases.

Sibling packages (jdocmunch-mcp, jdatamunch-mcp) remain on PyPI normally; no action needed there.

I won't re-ping PyPI in the interim. Duplicate tickets slow the queue.

Will post here when the simple-index meta flips back to active.

-jjg

[jgravelle]

Minor correction to the earlier timeline framing. Mike's May 26 return is when security@pypi.org specifically resumes full-time triage, but the broader admin@pypi.org alias is monitored by other PyPI admins who can clear quarantines independently. So May 26 is a worst-case backstop, not an ETA. The actual resolution could land any time before then if another admin picks the ticket up from the queue.

Also confirmed empirically (so anyone reading this knows what to expect):

• The quarantine is project-level, not release-level. The simple-index meta is pypi:project-status: quarantined, and the body has zero release links — so pip install jcodemunch-mcp==1.108.19 (or any other version pin) fails the same way as the unpinned form. All versions are gated together until the quarantine lifts.
• Maintainer uploads are blocked: tried twine upload for a clean v1.108.21 build → PyPI returned HTTP 403 Forbidden. So I can't even ship the small bug fix we'd otherwise queue for v1.108.21 (a thread-safety fix in progress.py) until the quarantine clears.

GitHub-release install paths and the repointed one-click badges in the README/QUICKSTART are the supported install channels meantime.

-jjg