Introduction

zsh: no matches found: requests[security] is a shell-expansion problem, not a pip or Python packaging problem. In zsh, square brackets are part of glob syntax, so an extras spec such as requests[security] is interpreted before pip ever sees it. The fix is to pass the package string literally by quoting or escaping it.

Why zsh Rejects the Command

zsh expands wildcards before it runs the command. That means this:

pip install requests[security]

is not treated as plain text. zsh reads [security] as a pattern character class. If no filenames in the current directory match that pattern, zsh stops with:

zsh: no matches found: requests[security]

The important detail is that pip was never the failing component.

Correct Ways To Install Package Extras

You need the shell to leave the argument unchanged.

Safest form:

python3 -m pip install 'requests[security]'

Escaped form:

python3 -m pip install requests\[security\]

Both work. Quoting is usually easier to read and copy into docs and scripts.

Why python -m pip Is Better Than Plain pip

This problem is about zsh, but it often appears alongside environment confusion. Using python -m pip makes the target interpreter explicit.

python -m pip --version
python3 -m pip --version

That matters on machines with:

• System Python and Homebrew Python.
• Virtual environments.
• 'pip pointing to a different interpreter than the one running your app.'

So the best command is usually:

python -m pip install 'requests[security]'

or, in a virtual environment:

python -m pip install 'requests[security]==2.32.3'

Temporary zsh-Specific Workarounds

zsh also has a noglob prefix that disables globbing for one command.

noglob pip install requests[security]

This is useful interactively, but it is not the best pattern for shared scripts. Quoting the package string is more explicit and portable across shells.

Some users also change zsh options such as nomatch, but that is a shell-wide behavior change and can create hard-to-debug inconsistencies between machines.

Requirements Files and CI

You do not need shell escaping inside requirements.txt because the shell is not parsing those lines.

Example:

requests[security]==2.32.3

Install it with:

python -m pip install -r requirements.txt

This is often the cleanest way to avoid shell quoting issues in CI pipelines and onboarding docs.

In CI, also prefer explicit version logging:

python --version
python -m pip --version
python -m pip install -r requirements.txt

That makes interpreter mismatch easier to diagnose.

The Same Issue Appears With Other Extras

This is not specific to requests. The same problem appears with any package extras syntax in zsh, for example:

• 'uvicorn[standard]'
• 'httpx[socks]'
• 'celery[redis]'

If square brackets are in the package spec, quote the argument.

Documentation and Team Hygiene

If you write README or setup instructions for a team, quote extras in every example. Otherwise macOS users with default zsh shells will hit this immediately.

Good docs:

python -m pip install 'uvicorn[standard]'
python -m pip install 'requests[security]'

Bad docs:

pip install uvicorn[standard]

That single omission creates repeated onboarding friction.

Common Pitfalls

• Blaming pip when zsh prevented the command from executing. Fix by recognizing this as a shell-parsing error.
• Using unquoted extras syntax in zsh. Fix by quoting or escaping the package spec.
• Using plain pip tied to the wrong interpreter. Fix by using python -m pip.
• Relying on shell-option tweaks instead of explicit quoting. Fix by keeping commands portable and literal.
• Forgetting to quote extras in documentation and CI snippets. Fix by standardizing quoted examples everywhere.

Summary

• 'zsh: no matches found for requests[security] is caused by shell globbing.'
• Quote or escape the extras spec so pip receives the literal string.
• Prefer python -m pip to avoid interpreter mismatch.
• Requirements files avoid this shell-parsing issue entirely.
• The same quoting rule applies to any package extras syntax used in zsh.