PYTHONSAFEPATH still includes the current directory on Windows for script entrypoints

Bug report

Bug description:

We tried to support PYTHONSAFEPATH in coverage.py (pull request), and had a problem where Windows didn't behave the same as MacOS or Linux. I decided to make a small test repo for checking how it behaved natively in Python, and I think I've found a discrepancy.

The test repo is here: https://github.com/nedbat/safe-path-tests

The code prints a number of values from the sys module. Tox and GitHub Actions are used to run the code in a number of different ways on all three operating systems. Below are excerpts from the action runs, with links to the appropriate spots in the full runs.

When installing the code as an executable script entrypoint and run normally, the first entry in sys.path indicates the source of the code:

Windows (full action run):

py311: commands[21]> safepathtests
================================================================================
3.11.9 (tags/v3.11.9:de54cf5, Apr  2 2024, 10:12:12) [MSC v.1938 64 bit (AMD64)]
sys.argv = ['D:\\a\\safe-path-tests\\safe-path-tests\\.tox\\py311\\Scripts\\safepathtests.EXE']
os.getcwd() = 'D:\\a\\safe-path-tests\\safe-path-tests'
__file__ = 'D:\\a\\safe-path-tests\\safe-path-tests\\.tox\\py311\\Lib\\site-packages\\safepathtests\\work.py'
sys.path:
  0: D:\a\safe-path-tests\safe-path-tests\.tox\py311\Scripts\safepathtests.EXE
  1: C:\hostedtoolcache\windows\Python\3.11.9\x64\python311.zip
  2: C:\hostedtoolcache\windows\Python\3.11.9\x64\DLLs
  3: C:\hostedtoolcache\windows\Python\3.11.9\x64\Lib
  4: C:\hostedtoolcache\windows\Python\3.11.9\x64
  5: D:\a\safe-path-tests\safe-path-tests\.tox\py311
  6: D:\a\safe-path-tests\safe-path-tests\.tox\py311\Lib\site-packages

sys.flags:
  ignore_environment: 0
  isolated: 0
  safe_path: False

MacOS (full action run):

py311: commands[21]> safepathtests
================================================================================
3.11.9 (v3.11.9:de54cf5be3, Apr  2 2024, 07:12:50) [Clang 13.0.0 (clang-1300.0.29.30)]
sys.argv = ['/Users/runner/work/safe-path-tests/safe-path-tests/.tox/py311/bin/safepathtests']
os.getcwd() = '/Users/runner/work/safe-path-tests/safe-path-tests'
__file__ = '/Users/runner/work/safe-path-tests/safe-path-tests/.tox/py311/lib/python3.11/site-packages/safepathtests/work.py'
sys.path:
  0: /Users/runner/work/safe-path-tests/safe-path-tests/.tox/py311/bin
  1: /Library/Frameworks/Python.framework/Versions/3.11/lib/python311.zip
  2: /Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11
  3: /Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/lib-dynload
  4: /Users/runner/work/safe-path-tests/safe-path-tests/.tox/py311/lib/python3.11/site-packages

sys.flags:
  ignore_environment: 0
  isolated: 0
  safe_path: False

But when run with PYTHONSAFEPATH=1, Windows still has the same first entry in sys.path while MacOS is missing it. I would expect it to be missing:

Windows (full action run):

py311: commands[22]> env PYTHONSAFEPATH=1 safepathtests
================================================================================
3.11.9 (tags/v3.11.9:de54cf5, Apr  2 2024, 10:12:12) [MSC v.1938 64 bit (AMD64)]
sys.argv = ['D:\\a\\safe-path-tests\\safe-path-tests\\.tox\\py311\\Scripts\\safepathtests']
os.getcwd() = 'D:\\a\\safe-path-tests\\safe-path-tests'
__file__ = 'D:\\a\\safe-path-tests\\safe-path-tests\\.tox\\py311\\Lib\\site-packages\\safepathtests\\work.py'
sys.path:
  0: D:\a\safe-path-tests\safe-path-tests\.tox\py311\Scripts\safepathtests.exe
  1: C:\hostedtoolcache\windows\Python\3.11.9\x64\python311.zip
  2: C:\hostedtoolcache\windows\Python\3.11.9\x64\DLLs
  3: C:\hostedtoolcache\windows\Python\3.11.9\x64\Lib
  4: C:\hostedtoolcache\windows\Python\3.11.9\x64
  5: D:\a\safe-path-tests\safe-path-tests\.tox\py311
  6: D:\a\safe-path-tests\safe-path-tests\.tox\py311\Lib\site-packages

sys.flags:
  ignore_environment: 0
  isolated: 0
  safe_path: True

MacOS (full action run):

py311: commands[22]> env PYTHONSAFEPATH=1 safepathtests
================================================================================
3.11.9 (v3.11.9:de54cf5be3, Apr  2 2024, 07:12:50) [Clang 13.0.0 (clang-1300.0.29.30)]
sys.argv = ['/Users/runner/work/safe-path-tests/safe-path-tests/.tox/py311/bin/safepathtests']
os.getcwd() = '/Users/runner/work/safe-path-tests/safe-path-tests'
__file__ = '/Users/runner/work/safe-path-tests/safe-path-tests/.tox/py311/lib/python3.11/site-packages/safepathtests/work.py'
sys.path:
  0: /Library/Frameworks/Python.framework/Versions/3.11/lib/python311.zip
  1: /Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11
  2: /Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/lib-dynload
  3: /Users/runner/work/safe-path-tests/safe-path-tests/.tox/py311/lib/python3.11/site-packages

sys.flags:
  ignore_environment: 0
  isolated: 0
  safe_path: True

The pattern continues in Python 3.12 and 3.13 as well. Linux behaves as MacOS does.

Is this correct behavior? Why does Windows keep the first sys.path entry when MacOS and Linux do not?

BTW: #123121 sounds similar, but I don't know if it's related.

Let me know if any of this is unclear, I'll try to explain. The test repo gets a bit intricate.

CPython versions tested on:

3.11, 3.12, 3.13

Operating systems tested on:

Linux, macOS, Windows

Linked PRs

gh-131484: Document that directory and zipfile script targets stay on sys.path #154853

The platform difference comes from how the entry point is executed, not from
Windows path handling: pip's Windows entry points are exe launchers with an appended
zip archive — the launcher starts a child Python process with its own .exe path as
the script argument — so they take the zipapp code path, while POSIX entry points are
plain scripts. Reproduced with 3.14.6 and with main at 8b048eb (3.16.0a0):

> python -P plain.py                # script directory not prepended, as documented
> python -P app.pyz                 # sys.flags.safe_path is set, yet sys.path[0] = '...\app.pyz'
> PYTHONSAFEPATH=1 python app.pyz   # same result
> python -I app.pyz                 # also unchanged in isolated mode

Root cause: in pymain_set_path0() (Modules/main.c), the main_importer_path branch
(directory/zipfile targets) prepends unconditionally; only the non-importer branch
consults config->safe_path:

cpython/Modules/main.c

Lines 701 to 718 in 8b048eb

    
           static int 
        
           pymain_set_path0(PyObject *main_importer_path) 
        
           { 
        
               PyConfig *config = (PyConfig *)_Py_GetConfig(); 
        
               PyObject *path0 = NULL; 
        
               if (main_importer_path != NULL) { 
        
                   path0 = Py_NewRef(main_importer_path); 
        
               } 
        
               else if (!config->safe_path) { 
        
                   int res = _PyPathConfig_ComputeSysPath0(&config->argv, &path0); 
        
                   if (res < 0) { 
        
                       return -1; 
        
                   } 
        
                   else if (res == 0) { 
        
                       Py_CLEAR(path0); 
        
                   } 
        
               }

Skipping the insertion under -P would not be a fix by itself: __main__ is then
looked up generically on sys.path, so startup would fail — or import an unrelated
__main__.

So the question is whether keeping the explicitly named execution target on
sys.path under -P is intended. The <script> docs already say a directory/zipfile
target is prepended; the -P docs just don't cover that case. If intended, I have a
short docs patch ready. If the behavior should change, it would need target-bound
loading of __main__ plus an import-precedence decision.

(AI tools assisted this analysis; I reproduced the behavior and checked the cited
source myself.)

Navigation Menu

Repository navigation

PYTHONSAFEPATH still includes the current directory on Windows for script entrypoints #131484

Bug report

Bug description:

CPython versions tested on:

Operating systems tested on:

Linked PRs

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

	static int
	pymain_set_path0(PyObject *main_importer_path)
	{
	PyConfig config = (PyConfig )_Py_GetConfig();

	PyObject *path0 = NULL;
	if (main_importer_path != NULL) {
	path0 = Py_NewRef(main_importer_path);
	}
	else if (!config->safe_path) {
	int res = _PyPathConfig_ComputeSysPath0(&config->argv, &path0);
	if (res < 0) {
	return -1;
	}
	else if (res == 0) {
	Py_CLEAR(path0);
	}
	}

PYTHONSAFEPATH still includes the current directory on Windows for script entrypoints #131484

Description

Bug report

Bug description:

CPython versions tested on:

Operating systems tested on:

Linked PRs

Activity

yhay81 commented on Jul 29, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions