What does pip's no-require-hashes option do, and should you use it?

It turns off the rule that makes one hashed requirement force hashes on all requirements. Added in pip 26.2, it lets you combine hashed packages with local directories or version control URLs. Hashes are then checked only where you provide them, so every unhashed line becomes a gap you must justify.

The rule it relaxes

Pip's hash-checking mode is all or nothing. The secure installs guide says that specifying a hash against any requirement activates the mode globally, and that hashes are then required for all requirements and all dependencies. The reasoning is sound: a partly hashed file is of little use, because an attacker could slip bad code in through an unhashed line.

That rule has a side effect, which the documentation names itself. It notably prevents the combination of hashed requirements with local directories or VCS URLs, since you cannot give a local checkout a useful registry hash.

What changed in 26.2

The same guide documents the addition under "Added in version 26.2". By default, when at least one requirement has hashes, hashes become required for all. A no-require-hashes flag is available to disable that mechanism, and hashes are then verified only for requirements where they are provided.

python -m pip install --no-require-hashes -r requirements.txt

Note the wording matters. Pip still verifies the hashes you wrote. It simply stops insisting that everything has one.

When it is reasonable

A real use case is a monorepo where your own packages live in the same repository. Those local directories cannot carry a registry hash, but the third party packages they pull in can.

Before reaching for the flag, ask whether you can avoid it:

1. Build your internal packages into wheels, publish them to a controlled index, and hash those wheels like any other.
2. Pin a VCS dependency to a full commit, then build it into a wheel you hash. See pin a pip git dependency to a commit.
3. Install your own project last with dependencies disabled, as the pip guide advises, so the hashed list does the real dependency work.

If none of those fit, use the flag, but narrow its blast radius.

Guardrails if you use it

• Keep every third party package hashed. The flag should only excuse your own code.
• Add a check in CI that fails when a new line without a hash appears for a name you do not own.
• Record the decision where reviewers will see it, such as a comment above the line.
• Keep the strict mode for production images, and allow the relaxed mode only in development.

A simple review script can scan the requirements file and list lines that have no sha256 value. Anything on that list should be a local path or a VCS URL you can explain.

Where this sits in a pipeline

Hash enforcement is one gate. Another is knowing what you installed. Safeguard's policies and gates can block a pull request that introduces a new dependency, and its SBOM generation records the resolved set for later review. Pair that with the strict mode, and the relaxed flag stays a deliberate exception. A free scan is available at gold.safeguard.sh/scan.

Try it yourself

Click through it at your own pace, or open it full screen. Watch how a gate decides whether a change can merge.

Quick check

Sources

• pip documentation, Secure installs

Last reviewed: 19 October 2026.