Does pip's wheel cache skip hash checking?

No. Since pip 23.1, hash-checking mode also applies when pip installs from its cache of locally built wheels. Pip compares your recorded hash against the original source distribution that produced the wheel, using a record stored in the cache entry. The cache can still surprise you in other ways.

What the cache holds

Pip's caching guide describes two things stored on disk: HTTP responses, which behave like a browser cache, and locally built wheels. When there is no wheel for a source distribution, pip builds one, adds it to the cache, and reuses it for later installs of the same package version.

That second part is what raises the question. If a built wheel is reused, the file pip installs is not the file you hashed. You hashed the sdist from the index.

How verification still works

The secure installs guide addresses this directly under "Interaction with caching", marked changed in version 23.1. When installing from the cache of locally built wheels in hash-checking mode, pip verifies the hashes against those of the original source distribution that was used to build the wheel. The original hashes come from an origin.json file kept in each cache entry.

So the chain is: your requirement lists the sdist hash, the cache entry remembers which sdist it was built from, and pip compares the two before reusing the wheel.

What this does not protect

Be clear about the boundary.

• It verifies the input to the build, not the output. A build that behaves differently on two machines can still produce different wheels from the same sdist.
• If your local cache directory is writable by something untrusted, you have a larger problem than hashes. Treat the cache as part of the build environment.
• Paths installed directly from a local folder are different. The caching guide says wheels built from a source distribution provided as a direct path, such as installing the current directory, are not cached across runs.

A related gotcha: the cache assumes determinism

The caching guide also warns that pip assumes building a package from an index is deterministic. Its example is a package with optional C extensions that falls back to a pure Python wheel when the extension cannot be built. Pip will keep using that cached wheel later, even in an environment that could have built the extensions.

The recommended approach is to install directly from a source distribution, which forces a build, and to remove the offending cached wheel with the cache remove command. See also pip wheelhouse offline installs.

Practical settings

1. In CI, give each job a clean or well scoped cache rather than one shared by unrelated projects.
2. Use hash-checking mode in the image build so cached and fresh installs are held to the same standard.
3. Run the cache info command when debugging to see where the cache lives and how big it is.
4. Purge it when you suspect a stale build.

python -m pip cache info
python -m pip cache remove somepackage

Disabling the cache is possible, but the pip guide recommends not doing so unless you have caching at a higher level, such as layered caches in container builds. Faster builds are not worth much if they hide a bad cache entry, so measure both.

Safeguard's SBOM generation records the resolved package set of a build, which helps when you need to show what a cached install produced. A free scan is available at gold.safeguard.sh/scan.

Quick check

Sources

• pip documentation, Secure installs
• pip documentation, Caching

Last reviewed: 19 October 2026.