WARNING: pip is being invoked by an old script wrapper. This will fail in a future version of pip.

Q: How do I prevent pip:OLD_SCRIPT_WRAPPER in CI?

Standardize on `python -m pip` in team docs and automation. Avoid `sudo pip ...` (it commonly creates ownership and wrapper confusion). Use per-project virtual environments and keep PATH minimal.

Q: How can I manually validate pip:OLD_SCRIPT_WRAPPER?

Check which pip wrapper you're calling: `command -v pip` (or `where pip` on Windows). Compare with the interpreter: `python -c 'import sys; print(sys.executable)'` and `python -m pip --version`. If in a venv, confirm it's activated.

What pip Is Rejecting

You're running pip through an outdated entrypoint script. It still works today, but it can break after pip upgrades.

Fix the command

Preferred: switch to python -m pip ... everywhere (scripts, CI, docs), if you need the wrapper, reinstall pip in the active environment so wrappers are regenerated (python -m pip install --force-reinstall pip), and remove PATH entries for old Python installs or ensure the intended environment comes first.

Manual wrapper checks

Check which pip wrapper you're calling:command -v pip (or where pip on Windows).

Compare with the interpreter:python -c 'import sys; print(sys.executable)' and python -m pip --version

If in a venv, confirm it's activated.

Typical Output

WARNING: pip is being invoked by an old script wrapper. This will fail in a future version of pip.

Why the Command Was Rejected

Usually this comes down to you upgraded pip but your PATH still points to an older pip wrapper script, multiple Python environments exist and PATH is selecting the wrong one, or you are mixing system/user installs (or using sudo sometimes and not others).

Re-run the Minimal Correct Command

Run python -m pip --version and confirm it points to the expected environment, and re-run your pip command and confirm the wrapper warning no longer appears.

Why pip wrapper scripts get stale

pip is typically launched via a small wrapper script (pip, pip3, or pip.exe) created when pip is installed. If your PATH points to an old wrapper while the pip package has been upgraded (or installed elsewhere), pip warns that the wrapper may become incompatible.

Avoid Command and Config Drift

To prevent this, standardize on python -m pip in team docs and automation, avoid sudo pip ... (it commonly creates ownership and wrapper confusion), and use per-project virtual environments and keep PATH minimal.

Docs and source code

github.com/pypa/pip/blob/25.3/src/pip/_internal/utils/entrypoints.py

pip prints this warning when invoked through an old wrapper entrypoint, and recommends using python -m pip. - GitHub

def _wrapper(args: list[str] | None = None) -> int:
    """Central wrapper for all old entrypoints.

    Historically pip has had several entrypoints defined. Because of issues
    arising from PATH, sys.path, multiple Pythons, their interactions, and most
    of them having a pip installed, users suffer every time an entrypoint gets
    moved.

    To alleviate this pain, and provide a mechanism for warning users and
    directing them to an appropriate place for help, we now define all of
    our old entrypoints as wrappers for the current one.
    """
    sys.stderr.write(
        "WARNING: pip is being invoked by an old script wrapper. This will "
        "fail in a future version of pip.\n"
        "Please see https://github.com/pypa/pip/issues/5599 for advice on "
        "fixing the underlying issue.\n"
        "To avoid this problem you can invoke Python with '-m pip' instead of "
        "running pip directly.\n"
    )
    return main(args)