Issue Station
Sign In
Tools hereToolbox

codex - 💡(How to fix) Fix Windows sandbox blocks pytest-xdist temp dirs created with Python 3.14/pytest 0o700 permissions [1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openai/codex#19791•Fetched 2026-04-28 06:37:07
View on GitHub
Comments
0
Participants
1
Timeline
6
Reactions
0
Author
shaunecclesshauneccles
Participants
shaunecclesshauneccles
Timeline (top)
labeled ×4unlabeled ×2

Error Message

INTERNALERROR> PermissionError: [WinError 5] Access is denied: 'C:\Users\shaun\AppData\Local\Temp\pytest-of-shaun'

Root Cause

  1. Python/pytest creating temp directories with restrictive permissions (mode=0o700), including tmp_path, tmp_path_factory, and xdist worker basetemps.
  2. Codex's Windows sandbox/restricted token/ACL model not being able to access those owner-only directories after creation.
  3. xdist multiplying the problem because controller and workers exchange temp roots such as pytest-of-shaun\pytest-0\popen-gw*.

Fix Action

Fix / Workaround

Workarounds tested

The only successful in-repo workaround so far is very invasive: monkeypatching temp directory creation during tests so directories under the pytest temp root use sandbox-readable permissions, and patching xdist so workers do not receive controller-created fixed popen-gw* basetemps. That required touching Path.mkdir, os.mkdir, TMP/TEMP/TMPDIR, PYTEST_DEBUG_TEMPROOT, and xdist.workermanage.WorkerController.setup from tests/conftest.py.

That workaround is a strong smell; normal Python projects should not need to patch os.mkdir to run pytest in Codex.

Code Example

[tool.pytest.ini_options]
addopts = """
    -ra
    -q
    -n auto
    --dist loadfile
    --maxfail=3
    --tb=short
    --no-header
"""

---

uv run pytest tests/test_active_backlogs_current_schema.py -q

---

INTERNALERROR> PermissionError: [WinError 5] Access is denied: 'C:\Users\shaun\AppData\Local\Temp\pytest-of-shaun'

---

INTERNALERROR> PermissionError: [WinError 5] Access is denied: 'D:\Data\backlog-docgen\.pytest-tmp\run-...\pytest-of-shaun'

---

PermissionError: [WinError 5] Access is denied: 'D:\Data\backlog-docgen\.pytest-tmp\run-...\pytest-of-shaun\pytest-0\popen-gw1'

---

PermissionError: [WinError 5] Access is denied: 'D:\Data\backlog-docgen\.pytest-tmp\run-...\pytest-of-shaun\pytest-0\test_import_no_changes0\test-backlog'
RAW_BUFFERClick to expand / collapse

What version of Codex CLI is running?

codex-cli 0.125.0

Platform

Native Windows, PowerShell shell tool, workspace-write sandbox. Workspace is on D:\Data\backlog-docgen.

Python/test stack:

  • Python 3.14.3 (MSC v.1944 64 bit (AMD64))
  • pytest 9.0.2
  • pytest-xdist 3.8.0
  • pytest configured with -n auto --dist loadfile

Issue

Inside the Codex Windows sandbox, pytest-xdist fails when pytest creates temporary directories using its default private directory mode (0o700). The failures are Windows PermissionError: [WinError 5] Access is denied when pytest/xdist tries to reopen or scan temp directories that the same test run just created.

This looks like an interaction between:

  1. Python/pytest creating temp directories with restrictive permissions (mode=0o700), including tmp_path, tmp_path_factory, and xdist worker basetemps.
  2. Codex's Windows sandbox/restricted token/ACL model not being able to access those owner-only directories after creation.
  3. xdist multiplying the problem because controller and workers exchange temp roots such as pytest-of-shaun\pytest-0\popen-gw*.

Minimal reproduction shape

In a Python project with pytest-xdist installed and default xdist config:

[tool.pytest.ini_options]
addopts = """
    -ra
    -q
    -n auto
    --dist loadfile
    --maxfail=3
    --tb=short
    --no-header
"""

Run inside the Codex Windows sandbox:

uv run pytest tests/test_active_backlogs_current_schema.py -q

Representative failures seen while investigating:

INTERNALERROR> PermissionError: [WinError 5] Access is denied: 'C:\Users\shaun\AppData\Local\Temp\pytest-of-shaun'

After forcing temp roots into the workspace with PYTEST_DEBUG_TEMPROOT, failures moved to workspace-local pytest dirs:

INTERNALERROR> PermissionError: [WinError 5] Access is denied: 'D:\Data\backlog-docgen\.pytest-tmp\run-...\pytest-of-shaun'

With xdist worker basetemps:

PermissionError: [WinError 5] Access is denied: 'D:\Data\backlog-docgen\.pytest-tmp\run-...\pytest-of-shaun\pytest-0\popen-gw1'

With tests that use tmp_path/tmp_path_factory:

PermissionError: [WinError 5] Access is denied: 'D:\Data\backlog-docgen\.pytest-tmp\run-...\pytest-of-shaun\pytest-0\test_import_no_changes0\test-backlog'

With app code using tempfile.TemporaryDirectory(), the underlying PermissionError was converted by the FastAPI app into 403 responses.

Workarounds tested

These did not solve the underlying issue:

  • serial pytest only (-n 0) avoids xdist but is not practical for larger suites
  • fixed --basetemp=pytest-temp / --basetemp=tmp_pytest eventually becomes inaccessible after aborted or repeated runs
  • PYTEST_DEBUG_TEMPROOT alone keeps dirs in the workspace but still creates 0o700 dirs that the sandbox cannot reopen
  • unique per-run temp roots avoid name reuse but still fail once pytest/xdist creates nested private dirs

The only successful in-repo workaround so far is very invasive: monkeypatching temp directory creation during tests so directories under the pytest temp root use sandbox-readable permissions, and patching xdist so workers do not receive controller-created fixed popen-gw* basetemps. That required touching Path.mkdir, os.mkdir, TMP/TEMP/TMPDIR, PYTEST_DEBUG_TEMPROOT, and xdist.workermanage.WorkerController.setup from tests/conftest.py.

That workaround is a strong smell; normal Python projects should not need to patch os.mkdir to run pytest in Codex.

Related issues found

I searched openai/codex issues for:

  • pytest xdist PermissionError 0o700 Windows sandbox
  • pytest-of-shaun popen-gw PermissionError Windows sandbox
  • PYTEST_DEBUG_TEMPROOT pytest-of-shaun Windows sandbox
  • 0o700 Windows sandbox ACL Python tempfile

I did not find this exact issue.

Closest related Codex issues I found:

Related pytest issue:

Question

Is this expected behavior for the Windows sandbox? If yes, is there an intended way for common Python test tooling that creates 0o700 temp dirs (pytest/tmp_path/tmp_path_factory/tempfile + pytest-xdist workers) to run inside the sandbox without disabling xdist or broadening execution outside the sandbox?

From the user side, this looks like a very common combination: native Windows + Codex CLI sandbox + Python 3.14 + pytest + pytest-xdist. The expected behavior is that temp directories created by a sandboxed process remain accessible to that process and its sandboxed child worker processes for the duration of the test run.

extent analysis

TL;DR

The most likely fix is to modify pytest or pytest-xdist to use less restrictive permissions for temporary directories, allowing the Windows sandbox to access them.

Guidance

  • Investigate modifying the pytest configuration to use a different temporary directory permission setting, potentially by patching os.mkdir or Path.mkdir to use a more permissive mode.
  • Consider modifying the xdist worker setup to avoid creating private directories with restrictive permissions.
  • Review the related issues and discussions on GitHub to see if there are any existing solutions or workarounds that can be applied.
  • Evaluate the feasibility of using a different testing framework or tooling that does not create temporary directories with restrictive permissions.

Example

import os
import pytest

# Patch os.mkdir to use a more permissive mode
original_mkdir = os.mkdir
def patched_mkdir(path, mode=0o755):
    return original_mkdir(path, mode)
os.mkdir = patched_mkdir

Notes

The provided workaround of monkeypatching os.mkdir and xdist is invasive and may have unintended consequences. A more robust solution would be to modify the underlying testing framework or tooling to use less restrictive permissions for temporary directories.

Recommendation

Apply a workaround by modifying the pytest configuration or patching os.mkdir to use a more permissive mode, as the issue is likely due to the restrictive permissions used by pytest for temporary directories.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#runtime error#dependency conflict#environment setup#docker error

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

codex - 💡(How to fix) Fix Windows sandbox blocks pytest-xdist temp dirs created with Python 3.14/pytest 0o700 permissions [1 participants]