Native Codex Security scan cannot write to its app-managed Temp directory on Windows
What version of the Codex App are you using (From “About Codex” dialog)?
26.707.12708.0
What subscription do you have?
Pro
What platform is your computer?
Windows 11 25H2, OS build 26200.8875, x64
PowerShell-reported version: Microsoft Windows NT 10.0.26200.0 x64
What issue are you seeing?
A native Codebase security scan started through the Codex App successfully creates a running scan, but it stops before any security analysis because it cannot create its first artifact directory inside the authoritative scanDir supplied by the app.
The app supplied a directory shaped like:
C:\Users\<WindowsUser>\AppData\Local\Temp\codex-security-scans-<suffix>\<repository>\<scan-id>
After capability preflight completed successfully and the scan goal was created, the first artifact operation attempted to create the scan's artifacts directory. Windows returned:
[WinError 5] Access is denied: '...\artifacts'
The scan remains marked as running but cannot advance beyond preflight. No source-code analysis or report generation begins.
The repository, Git state, ACLs, configuration, and plugin files were not modified by the scan.
What steps can reproduce the bug?
- Open a trusted local Git repository in the Codex App on Windows.
- Use the native
$codex-security:security-scanworkflow. - Select Codebase scan mode with Deep scan disabled.
- Select a small repository-relative directory as the scan scope.
- In the native Codex Security setup workspace, verify the target and press Start scan.
- Allow the scan to load its authoritative context and generated
scanDirunderC:\Users\<WindowsUser>\AppData\Local\Temp\codex-security-scans-<suffix>\.... - Complete the capability preflight successfully.
- Let the workflow attempt to generate its first required artifact, such as
artifacts\01_context\security_guidance.md. - Observe that creating the parent
artifactsdirectory fails with[WinError 5] Access is denied.
The scan used the app-provided directory exclusively. The prompt explicitly prohibited ACL, configuration, plugin, repository, branch, and worktree changes so that no workaround could obscure the underlying failure.
Codex task ID: 019f6c4e-e4e9-71a2-9ec4-735325a51773
Codex Security scan ID: ae117913-08d8-4c22-82d9-7fe7365f3a49
What is the expected behavior?
A native Codex Security scan should be able to create and update its required artifacts inside the authoritative scanDir generated by the Codex App.
The app should either:
- provision that exact directory as writable for the scan process; or
- expose a host-managed artifact writer that safely writes into the directory.
Users should not need to modify Windows ACLs, grant write access to all of %TEMP%, edit project configuration for a randomly generated directory, enable full access, or approve repeated per-artifact workarounds.
After successful preflight, the scan should advance into threat modeling and discovery instead of blocking on its first artifact.
Additional information
Environment:
- Codex App package:
26.707.12708.0 - Codex Security plugin:
0.1.11 - Platform:
Windows 11 25H2, OS build 26200.8875, x64 - Repository trust: trusted
- Active project sandbox mode:
workspace-write - Approval policy:
on-request - Approval reviewer:
auto_review
Read-only ACL inspection found:
- The Codex sandbox identity is an enabled member of
CodexSandboxUsers. CodexSandboxUsershas inheritedModifypermission on the Windows Temp directory and the existingcodex-security-scans-<suffix>\<repository>parent.- No Deny ACE was found on the inspected directories.
- The scan-specific leaf directory was never created.
This makes a broken NTFS ACL unlikely. The failure appears to occur at the Codex sandbox/product-integration boundary.
The project configuration does not add the randomly generated scan directory as a persistent writable root. I cannot claim complete configuration independence without a clean-configuration A/B test. However, requiring every trusted repository to preconfigure an unpredictable app-generated Temp path would defeat the purpose of the native Security workflow.
An attempted narrowly scoped persistent exception was rejected by Codex managed policy because it would extend the allowed path set outside the repository. No active configuration change occurred.
Auto-review is not a write-permission grant; it only reviews eligible escalation requests. The native workflow currently exposes no host-managed intermediate artifact-writing tool.
This is highly disruptive because the UI successfully starts and retains a running scan, but the scan cannot perform any analysis without the user debugging Codex's own generated artifact directory.
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗