Pip hash checking makes an install fail unless every package, including transitive ones, is pinned to an exact version and matches a hash stored in your requirements file. If an assistant adds a dependency without you recording its hash, the deploy stops instead of installing it.
What the mode enforces
According to pip's documentation, giving any requirement a hash turns hash-checking on for the whole install, and the require hashes flag (shown below) forces it explicitly, which suits deploy scripts. In this mode:
- Every requirement must have a hash.
- Every dependency, including transitive ones, must be listed and hashed. Anything unlisted causes an error.
- Requirements must be pinned with
==, a URL, or a filesystem path. - sha256 is recommended. md5, sha1 and sha224 are rejected.
- A package can carry several hashes, for example for different platform wheels.
An example
requests==2.32.3 \
--hash=sha256:<hash from your own verified download>
Generate hashes with pip hash against a file you have downloaded and inspected, or with a lock tool that records them. Then deploy with:
pip install --require-hashes -r requirements.txt
Why this helps with AI-edited files
An assistant might append a loose requirement such as a package name with no version. Without hash checking, pip resolves whatever is newest. With it, the install fails because the line is unpinned and unhashed, and a human has to look at the new line.
It also narrows the window for a slopsquatted name. The attacker's package would need to match a hash you wrote down, and you only write down a hash after looking at the package.
Caveats from the docs
- Hashes taken from the index page do not count as your local hashes, since they only detect download corruption.
- Forcing the mode fetches only the preferred archive for each package, so you may need
pip hashfor other archives. - Do not bypass pip with
setup.py install; the docs warn that route can download unchecked dependencies. Install your own project with pip and the no deps option, as the pip page describes.
Remember what it does not do
A hash proves the file is the one you reviewed. It says nothing about whether the package was safe when you reviewed it. Reviewing the package is still your job. See how to check an AI-suggested package.
Workflow tip
Keep a short input file with the packages you chose, and generate the hashed requirements file from it with a tool that records hashes. Review the generated file in the pull request. When an assistant wants a new package, it edits the input file, a human approves the name, and the hashes are regenerated. That keeps the decision visible and the install reproducible.
Quick check
Is hash checking worth it for a small internal script?
Often yes for anything deployed. For a throwaway local script it is overkill. Match the control to what the code can reach.
Sources
Last reviewed: 19 October 2026.