venv on Windows 11 with Python 3.13.7 includes global paths in sys.path despite include-system-site-packages = false, causing packages to be installed globally instead of in the venv

[jdstraye]

Bug report

Bug description:

Description

When creating and activating a virtual environment with Python 3.13.7 on Windows 11, sys.path includes global Python paths (e.g., C:\Program Files\Python313\python313.zip, C:\Program Files\Python313\DLLs, etc.), even though pyvenv.cfg has include-system-site-packages = false. This causes python -m pip install <package> to install packages to the global site-packages (C:\Program Files\Python313\Lib\site-packages) instead of the virtual environment's site-packages.

This breaks virtual environment isolation, requiring --target for every install, which is not the expected behavior.

Steps to Reproduce

1. Install Python 3.13.7 from the official Windows installer, ensuring "Add python.exe to PATH" is checked.

2. Open PowerShell 7.5.2.

3. Create a test directory and virtual environment:
   mkdir test_venv_bug
   cd test_venv_bug
   python -m venv .venv

4. Activate the virtual environment:
   ..venv\Scripts\Activate.ps1

5. Check sys.path:
   python -c "import sys; print('\n'.join(sys.path))"

Expected: Only venv paths (e.g., C:\path\to\test_venv_bug\.venv, C:\path\to\test_venv_bug\.venv\Lib\site-packages).

6. Check pyvenv.cfg (should have include-system-site-packages = false):
   Get-Content .venv\pyvenv.cfg

7. Install a test package:
   python -m pip install requests

8. Verify installation location:
   python -m pip list
   Get-ChildItem -Path .venv\Lib\site-packages | findstr requests
   Get-ChildItem -Path 'C:\Program Files\Python313\Lib\site-packages' | findstr requests

Expected: requests in .venv\Lib\site-packages; nothing in global.

Expected Behavior

• sys.path should only include virtual environment paths (no global C:\Program Files\Python313* paths).
• python -m pip install should install to .venv\Lib\site-packages.

Actual Behavior

• sys.path includes global paths:
  • C:\Program Files\Python313\python313.zip
  • C:\Program Files\Python313\DLLs
  • C:\Program Files\Python313\Lib
  • C:\Program Files\Python313
  • C:\Users\jdstr\Documents\GitHub\ndx_scalper.git.venv_ndx_scalper
  • C:\Users\jdstr\Documents\GitHub\ndx_scalper.git.venv_ndx_scalper\Lib\site-packages
• python -m pip install requests installs to global site-packages (C:\Program Files\Python313\Lib\site-packages), with warnings like "Target directory C:\Program Files\Python313\Lib\site-packages\certifi already exists."
• python -m pip list in venv shows only pip; packages are missing in venv.

Environment

• Python version: 3.13.7 (installed via official Windows installer)
• OS: Windows 11 24H2 (Build 26100.5074)
• Shell: PowerShell 7.5.2
• pyvenv.cfg contents:

home = C:\Program Files\Python313
include-system-site-packages = false
version = 3.13.7
executable = C:\Program Files\Python313\python.exe
command = C:\Program Files\Python313\python.exe -m venv C:\Users\jdstr\Documents\GitHub\ndx_scalper.git.venv_ndx_scalper

• Activated venv prompt: (.venv) PS ...
• Get-Command python and Get-Command pip point to venv Scripts\python.exe and Scripts\pip.exe.

Additional Notes

• Using --target=.venv\Lib\site-packages works as a workaround, but it's cumbersome.
• Searched GitHub issues and Stack Overflow—no exact match, but similar to older Windows venv path leaks (e.g., pip [3.7] Fixed missing colun in library/sys.po (GH-11153) #11154).
• No antivirus or custom configs interfering (standard setup).

Minimal Reproducible Example

See "Steps to Reproduce" above. The test directory can be zipped and attached if needed.

Thanks for looking into this—it's breaking venv isolation on Windows.

CPython versions tested on:

3.13

Operating systems tested on:

Windows

[frostming]

Your issue is not caused by the reason you guessed. C:\Program Files\Python313\python313.zip and C:\Program Files\Python313\DLLs are paths to the Python standard library, and of course, they should be included in sys.path, otherwise you won't be able to import any standard library. Moreover, the target path for pip installation is not determined by sys.path but rather the installation scheme returned by sysconfig.get_paths().

Based on the information you provided, it is more likely that you are not using the correct interpreter in the virtual environment, especially these two items included in sys.path are questionable:

• C:\Users\jdstr\Documents\GitHub\ndx_scalper.git.venv_ndx_scalper
• C:\Users\jdstr\Documents\GitHub\ndx_scalper.git.venv_ndx_scalper\Lib\site-packages

They do not belong to this virtual environment.

The following command can check which pip you are actually using:

python -m pip --version

[jdstraye]

Thanks for the quick response and clarification! I’ve resolved the issue and gathered more details. I think there is still something for you to look into.

You are right that it was just a guess. In fact, it was grok's guess, not even mine.
The files you referenced are in my actual venv and were just rendered incorrectly because of the backslash in Windows/DOS. I thought that I had sanitized everything, but apparently I missed changing .venv_ndx_scalper to .venv there. Mea culpa. Sorry for dragging your time. My directory structure is

C:\Users\jdstr\Documents\GitHub\ndx_scalper.git
+---.venv_ndx_scalper/
+---src/
        ndx_scalper.py
        test_requests.py
    .gitignore
    README.md

The core issue was that pip install <package> and python -m pip install <package> installed to the global site-packages (C:\Program Files\Python313\Lib\site-packages) instead of the venv’s site-packages, despite using the correct interpreter and sysconfig.get_paths() pointing to the venv. I was using --target as a workaround, which was cumbersome compared to my smoother setups on Debian 12.

Root Cause: pip install.target

I found the cause:

python -m pip config list:
install.target='C:\Program Files\Python313\Lib\site-packages'

This was set in:

C:\ProgramData\pip\pip.ini:
[install]
target = C:\Program Files\Python313\Lib\site-packages

Other config files were absent:

• C:\Users\jdstr\AppData\Roaming\pip\pip.ini: not found
• C:\Program Files\Python313\pip.ini: not found

Environment variables were good:
$env:PIP_TARGET: [not set]
$env:PIP_CONFIG_FILE: [not set]

Fix

I removed the config file:

Remove-Item -Path C:\ProgramData\pip\pip.ini

Now python -m pip config list is empty.

Tested install:

python -m pip uninstall requests certifi charset-normalizer idna urllib3 -y
python -m pip install requests
python -m pip list: 
# Shows requests 2.32.5, certifi 2025.8.3, charset-normalizer 3.4.3, idna 3.10, urllib3 2.5.0, plus project packages

Get-ChildItem -Path .venv_ndx_scalper\Lib\site-packages | findstr requests:
  d---- 9/9/2025 11:05 AM requests
  d---- 9/9/2025 11:05 AM requests-2.32.5.dist-info
Get-ChildItem -Path 'C:\Program Files\Python313\Lib\site-packages' | findstr requests: 
# Shows requests, requests-2.32.5.dist-info (from prior tests)
python -c "import requests; print(requests.__version__)": 2.32.5

Result: pip now installs to .venv_ndx_scalper\Lib\site-packages, and imports use the venv’s packages. The issue is resolved!

Question

I didn’t manually set install.target. Could Python 3.13.7’s installer, pip 25.2, or a tool (e.g., VS Code) have created C:\ProgramData\pip\pip.ini? This seems like a potential bug, as it breaks virtual environment isolation.

Your guidance led me down this path. Thank you.

Interpreter and Pip Verification

Prompt: (.venv_ndx_scalper) PS C:\Users\jdstr\Documents\GitHub\ndx_scalper.git>
# clearly showing active venv and my directory.

Get-Command python: C:\Users\jdstr\Documents\GitHub\ndx_scalper.git\.venv_ndx_scalper\Scripts\python.exe

Get-Command pip: C:\Users\jdstr\Documents\GitHub\ndx_scalper.git\.venv_ndx_scalper\Scripts\pip.exe

python -m pip --version:
pip 25.2 from C:\Users\jdstr\Documents\GitHub\ndx_scalper.git\.venv_ndx_scalper\Lib\site-packages\pip (python 3.13)

sysconfig.get_paths()

python -c "import sysconfig; print(sysconfig.get_paths()['purelib'])":
C:\Users\jdstr\Documents\GitHub\ndx_scalper.git\.venv_ndx_scalper\Lib\site-packages

# Environment Variables

$env:PYTHONPATH: [not set]
$env:VIRTUAL_ENV: C:\Users\jdstr\Documents\GitHub\ndx_scalper.git\.venv_ndx_scalper

python -m site
sys.path = [
    'C:\\Users\\jdstr\\Documents\\GitHub\\ndx_scalper.git',
    'C:\\Program Files\\Python313\\python313.zip',
    'C:\\Program Files\\Python313\\DLLs',
    'C:\\Program Files\\Python313\\Lib',
    'C:\\Program Files\\Python313',
    'C:\\Users\\jdstr\\Documents\\GitHub\\ndx_scalper.git\\.venv_ndx_scalper',
    'C:\\Users\\jdstr\\Documents\\GitHub\\ndx_scalper.git\\.venv_ndx_scalper\\Lib\\site-packages',
]
USER_BASE: 'C:\\Users\\jdstr\\AppData\\Roaming\\Python' (exists)
USER_SITE: 'C:\\Users\\jdstr\\AppData\\Roaming\\Python\\Python313\\site-packages' (exists)
ENABLE_USER_SITE: False

Windows Details

Windows 11 Build: [Insert from winver, e.g., 23H2, Build 22631]
PowerShell: 7.5.2

cmd Test

Tested in cmd to rule out PowerShell issues, but the issue remained. Of course, we now know that it remained during this test because of the .ini override.

cd C:\Users\jdstr\Documents\GitHub\ndx_scalper.git
.venv_ndx_scalper\Scripts\activate.bat
python -m pip config list: [Insert, e.g., empty]
python -c "import sysconfig; print(sysconfig.get_paths()['purelib'])": [Insert]
python -m pip install requests
dir .venv_ndx_scalper\Lib\site-packages | findstr requests: [Insert]
dir "C:\Program Files\Python313\Lib\site-packages" | findstr requests: [Insert]
python -c "import requests; print(requests.__version__)": [Insert]

Next Steps

Should I close the issue, test Python 3.11.9, or provide pip debug info to investigate install.target’s origin? Thanks for your help!

[frostming]

Sorry I can't answer your question, need to wait for a Windows Installer expert.

[mrmundt]

This may or may not be related, so please let me know if I should open a new issue, but we are also experiencing some strange behavior in controlled environments. We started seeing incorrect behavior specifically on Windows with respect to pip finding the correct environment variables / registry information. (Full GHA can be seen here: https://github.com/mrmundt/pyomo/actions/runs/17734905599/job/50394322242)

Basic gist:

1. Windows (both 2022 and 2025 servers)
2. Python 3.13.7
3. Miniconda (conda version: 25.7.0)

We install a set of packages using conda install, but there are a few that are only available through pip. When attempting to pip config, pip debug, pip install, anything pip, it returns an error similar to:

Traceback (most recent call last):
  File "<frozen runpy>", line 198, in _run_module_as_main
  File "<frozen runpy>", line 88, in _run_code
  File "C:\Miniconda\envs\test\Lib\site-packages\pip\__main__.py", line 24, in <module>
    sys.exit(_main())
             ~~~~~^^
  File "C:\Miniconda\envs\test\Lib\site-packages\pip\_internal\cli\main.py", line 65, in main
    cmd_name, cmd_args = parse_command(args)
                         ~~~~~~~~~~~~~^^^^^^
  File "C:\Miniconda\envs\test\Lib\site-packages\pip\_internal\cli\main_parser.py", line 79, in parse_command
    general_options, args_else = parser.parse_args(args)
                                 ~~~~~~~~~~~~~~~~~^^^^^^
  File "C:\Miniconda\envs\test\Lib\optparse.py", line 1371, in parse_args
    values = self.get_default_values()
  File "C:\Miniconda\envs\test\Lib\site-packages\pip\_internal\cli\parser.py", line 283, in get_default_values
    self.config.load()
    ~~~~~~~~~~~~~~~~^^
  File "C:\Miniconda\envs\test\Lib\site-packages\pip\_internal\configuration.py", line 127, in load
    self._load_config_files()
    ~~~~~~~~~~~~~~~~~~~~~~~^^
  File "C:\Miniconda\envs\test\Lib\site-packages\pip\_internal\configuration.py", line 258, in _load_config_files
    config_files = dict(self.iter_config_files())
  File "C:\Miniconda\envs\test\Lib\site-packages\pip\_internal\configuration.py", line 353, in iter_config_files
    config_files = get_configuration_files()
  File "C:\Miniconda\envs\test\Lib\site-packages\pip\_internal\configuration.py", line 73, in get_configuration_files
    os.path.join(path, CONFIG_BASENAME) for path in appdirs.site_config_dirs("pip")
                                                    ~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^
  File "C:\Miniconda\envs\test\Lib\site-packages\pip\_internal\utils\appdirs.py", line 47, in site_config_dirs
    dirval = _appdirs.site_config_dir(appname, appauthor=False, multipath=True)
  File "C:\Miniconda\envs\test\Lib\site-packages\pip\_vendor\platformdirs\__init__.py", line 146, in site_config_dir
    ).site_config_dir
      ^^^^^^^^^^^^^^^
  File "C:\Miniconda\envs\test\Lib\site-packages\pip\_vendor\platformdirs\windows.py", line 67, in site_config_dir
    return self.site_data_dir
           ^^^^^^^^^^^^^^^^^^
  File "C:\Miniconda\envs\test\Lib\site-packages\pip\_vendor\platformdirs\windows.py", line 56, in site_data_dir
    path = os.path.normpath(get_win_folder("CSIDL_COMMON_APPDATA"))
                            ~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Miniconda\envs\test\Lib\site-packages\pip\_vendor\platformdirs\windows.py", line 209, in get_win_folder_from_registry
    directory, _ = winreg.QueryValueEx(key, shell_folder_name)
                   ~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^
FileNotFoundError: [WinError 2] The system cannot find the file specified

I have found that reverting to 3.13.5 is a workaround, so whatever is happening is restricted to 3.13.7. We have tried manually setting multiple environment variables (such as "CSIDL_COMMON_APPDATA"), "tricking" pip into using an empty config, running pip in --isolated mode.