Windows Codex App-generated apply_patch launcher can target an AppX executable inaccessible to the sandbox

Open 💬 7 comments Opened Aug 13, 2026 by specimba

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using (From “About Codex” dialog)?

26.803.10989.0

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

The Codex App can generate an apply_patch launcher that directly invokes an AppX-packaged codex.exe under C:\Program Files\WindowsApps\.... In my Windows task, the sandbox identity could read and write the approved workspace but could not execute that generated helper path. The patch operation stalled or failed with access denied and appeared to be a repository/configuration permission failure.

The same official apply-patch operation succeeded through the installed standalone Codex CLI 0.147.0:

C:\Users\<USER>\.codex\packages\standalone\current\bin\codex.exe --codex-run-as-apply-patch <PATCH>

No repository ACL reset, unrestricted permission profile, config.toml expansion, network access, or secret-file access was needed.

The observed App-generated launcher resolved to a path equivalent to:

C:\Program Files\WindowsApps\OpenAI.Codex_26.803.10989.0_x64__2p2nqsd0c76g0\app\resources\codex.exe --codex-run-as-apply-patch

The significant problem is diagnostic ambiguity: a helper-executable access failure looks like a repository write denial, which can encourage unnecessary filesystem and ACL changes.

This report does not claim an authorization bypass or data exposure. It is a reliability, permission-resolution, and diagnostics defect.

What steps can reproduce the bug?

On Windows, open a fresh Codex App task using a named managed workspace-write permission profile.
Give the profile write access only to a synthetic test workspace and temporary directory. Keep network restricted.
Confirm that the task can create, read, remove, and prove absence of a harmless file inside the approved workspace.
Ask the task to modify another harmless file using the official apply_patch helper.
Inspect the generated helper launcher. In the failing case it invoked an AppX-packaged executable under C:\Program Files\WindowsApps\OpenAI.Codex_<VERSION>_x64__...\app\resources\codex.exe.
Observe that helper execution stalls or fails with access denied even though direct create/read/remove operations in the target workspace succeed.
Pass the same UTF-8 patch text to the installed standalone Codex CLI 0.147.0:

~\.codex\packages\standalone\current\bin\codex.exe --codex-run-as-apply-patch <PATCH>

Observe that the standalone official helper applies the patch successfully under the existing bounded workspace policy.
Verify that no broad ACL change, danger-full-access profile, network permission, or unrelated filesystem write was required.

Reproduction environment:

Codex App package observed in launcher: 26.803.10989.0
Standalone comparison: codex-cli 0.147.0
Standalone target: x86_64-pc-windows-msvc
Platform: Microsoft Windows NT 10.0.26200.0 x64
PowerShell
Managed workspace-write policy with explicit writable roots
Restricted network
Non-escalatable secret/environment-file denials

The affected private task/session ID is withheld from this public issue and is being supplied to OpenAI Support for server-side correlation. The reproduction does not depend on private repository contents.

What is the expected behavior?

The Codex App should:

Select an apply-patch executable that is guaranteed to be executable by the intended sandbox identity.
Preflight the resolved helper path, existence, executable access, version, architecture, and required companion resources before dispatch.
Report helper-launch failures as helper executable inaccessible with the relevant Windows error code, rather than presenting them as a repository write failure or indefinite patch stall.
Display the Codex App version, embedded CLI version, standalone CLI version if detected, selected helper path, and helper hash in diagnostics.
Preserve the existing bounded filesystem policy; fixing the helper must not require broad filesystem access or ACL weakening.
Show an inspectable permission-resolution receipt containing:

requested profile identifier;
selected UI mode;
configuration source and precedence;
resolved profile identifier;
compiled policy hash;
managed-policy overrides;
readable, writable, and denied roots;
network policy;
explicit fallback reason or no_fallback.

Fail closed if a named profile is undefined and never silently substitute a different authority level.

A minimal acceptance test should use apply_patch on a harmless temporary file inside an approved writable workspace, read the result, remove it, and prove absence while recording exactly which executable performed the patch.

Additional information

The standalone official entrypoint succeeded under the same bounded-write policy, which indicates that the target repository and permission profile were not the underlying cause.

The App UI label Custom, a TOML named permission profile, default_permissions, and the effective managed runtime policy are also easy to confuse. Exposing a resolved profile identifier and compiled policy hash would substantially improve Windows permission debugging.

A separate private OpenAI Support case is being prepared for account-specific backend routing and TPM-reconnect behavior. I am intentionally not placing the organization/quota namespace, private task ID, raw rollout history, prompts, or account telemetry in this public issue.

Related product improvement observed in a separate long-running task: after the first TPM 429, Codex Desktop displayed repeated Reconnecting /5 attempts for an unchanged large request. A safer client admission design would fingerprint rejected requests, suppress unchanged resubmission until provider reset or Retry-After plus jitter, and share one end-to-end retry budget across SDK and Desktop reconnect layers. This observation is not required to reproduce the Windows apply-patch bug and can be split into a separate issue if maintainers prefer.

No API keys, credentials, confidential third-party data, or private repository contents are included.

View original on GitHub ↗

7 Comments

github-actions[bot] contributor · 14 days ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

#38190

Powered by Codex Action

specimba · 7 days ago

Fresh post-restart evidence:

After installing the validated global/project permission configuration and fully restarting Codex Desktop, the task entered the expected managed read-only baseline with restricted network and non-escalatable .env/.env.* denials.

However, the first ordinary no-op command:

Write-Output 'NEXUS_EXEC_NOOP_PASS'

produced no output and remained running for more than 31 seconds. The attempt was then terminated. No escalation, filesystem write, network access, or retry occurred.

This indicates that the failure is not limited to apply_patch and is not caused by insufficient workspace write permission. The ordinary command-execution bridge can also stall before returning any output.

There is also an effective-policy discrepancy: the configuration requests:

approvals_reviewer = "user"

but this task's effective runtime still reports:

approvals_reviewer = "auto_review"

Please investigate whether a managed/Desktop configuration layer is overriding or failing to reload that setting, and correlate the stalled no-op with the command-runner/code-mode-host telemetry for the task.

specimba · 7 days ago

Additional A/B evidence after switching to the validated nexus_autonomous
managed profile:

The runtime exposed workspace-write successfully, including the intended
writable roots:

C:\Users\speci.000\Documents\NEXUS
C:\Users\speci.000\Documents\NEXUS\.agents
C:\Users\speci.000\Documents\NEXUS\.nexus_pi
C:\tmp

Network remained restricted and all .env/.env.* denials remained active.

Despite that, the first harmless ordinary command:

Write-Output 'NEXUS_EXEC_NOOP_PASS'

again produced no output and remained running for 31 seconds before being
terminated. No escalation, network access, filesystem mutation, or retry
occurred.

The same no-op previously stalled under the read-only profile. It therefore
reproduces under both read-only and workspace-write managed profiles. This
rules out insufficient writable-root configuration as the cause and suggests
the failure is in the Desktop command/tool launch bridge, code-mode host, or
command-runner lifecycle before ordinary shell output is returned.

The effective runtime also continues to report approvals_reviewer=auto_review
despite the intended configuration requesting approvals_reviewer=user. Please
check whether a managed/Desktop configuration layer is overriding or failing
to reload that setting.

specimba · 7 days ago

The command-bridge failure still reproduces on Windows Codex Desktop
26.818.2872.0 after a confirmed clean application exit with no surviving Codex
processes. After reopening, the normal codex.exe -> codex-code-mode-host.exe
process relationship was present, but an ordinary exact Get-Content operation
remained running without output for 31 seconds plus a 10-second poll. No
codex-command-runner process or attached app terminal was established. This
rules out a lingering previous-version helper process and continues to indicate
a failure before shell attachment.

specimba · 7 days ago

Additional reproduction after complete local recovery

The command-bridge failure still reproduces after all of the following:

update to Windows Codex Desktop 26.818.2872.0;
confirmed full application exit with no surviving Codex processes;
full Windows restart;
Windows Settings → Codex → Advanced options → Repair;
reopening the NEXUS project under its normal managed workspace-write profile.

After that recovery sequence, one ordinary read-only command was submitted to
read an existing Markdown file. The tool invocation entered a running state but
produced no stdout, stderr, or exit code for 31 seconds. Polling the same
invocation once for an additional 10 seconds produced no change, after which it
was terminated. No duplicate command was launched.

The Codex app’s terminal inspection reports:

No app terminal session is attached to this thread yet.

No codex-command-runner terminal became available. The failure therefore
occurs before PowerShell execution and before filesystem authorization or the
target file can be involved.

No Full Access, unsandboxed execution, ACL weakening, network access, or
repository mutation was used. The same managed profile previously exposed the
expected NEXUS writable roots and preserved all .env denials.

This now appears to be a persistent Desktop code-mode-host/tool-bridge defect,
rather than stale process state, application repair state, project
configuration, or command syntax.

Please correlate the failed tool invocation through the task’s internal
Desktop/code-mode-host telemetry. In particular, please check:

whether the tool invocation was delivered to codex-code-mode-host.exe;
whether a command-runner launch was attempted;
the generated helper executable path and launch error, if any;
whether AppContainer/restricted-token access rejected that executable;
why the UI retained a running cell without surfacing a terminal-attachment

or helper-launch failure;

why no bounded timeout converted the bridge failure into a user-visible

error.

No recording was deliberately produced because support previously confirmed
that reproducing the issue solely for recording is not required.

specimba · 7 days ago

New evidence: ordinary managed command also stalls in a brand-new task

This is a material extension of the original apply_patch/AppX reproduction.

After App Repair, a complete Windows restart, Codex Desktop restart/update,
permission-profile reselection, and creation of a brand-new Codex task, I ran
exactly one read-only managed command:

$pwd.Path

patricio4-wsl · 2 hours ago

Seguimiento a solicitud del usuario. Codex Desktop identificó este issue como pertinente y realizó este informe técnico desde el propio entorno Desktop.

En Windows, con codex-cli 0.149.1 tanto en Desktop como en la CLI standalone, observamos lo siguiente en el mismo workspace privado:

Codex Desktop puede realizar inspección y varias validaciones read-only, pero apply_patch falla con Access denied / Failed to write file incluso al crear un archivo temporal inocuo.
En un intento, quedó creado un archivo vacío, pero Desktop no pudo escribir su contenido ni eliminarlo mediante apply_patch.
La CLI standalone aplica el mismo tipo de parche correctamente en ese workspace.
No se cambiaron ACLs, owner, WindowsApps, permisos del repositorio ni el modo de sandbox; evitamos precisamente esas intervenciones porque el contraste Desktop/CLI apunta al helper o a su identidad efectiva, no al código del proyecto.

Impacto práctico: el usuario puede trabajar normalmente en Desktop para análisis, revisión y pruebas compatibles, pero debe pasar a CLI para cualquier edición mediante apply_patch.

El análisis no inspeccionó ni expone contenido del repositorio, rutas personales, SIDs, credenciales ni datos privados. Sería muy útil que Desktop distinguiera de forma explícita un fallo de lanzamiento/autorización del helper de un fallo de escritura del workspace.

---

English translation

Follow-up at the user's request. Codex Desktop identified this issue as relevant and produced this technical report from within the Desktop environment itself.

On Windows, using codex-cli 0.149.1 in both Desktop and the standalone CLI, we observed the following in the same private workspace:

Codex Desktop can perform inspection and several read-only validations, but apply_patch fails with Access denied / Failed to write file even when creating a harmless temporary file.
In one attempt, an empty file was created, but Desktop could neither write its content nor delete it through apply_patch.
The standalone CLI applies the same kind of patch successfully in that workspace.
No ACLs, owner, WindowsApps installation, repository permissions, or sandbox mode were changed. We deliberately avoided those interventions because the Desktop/CLI contrast points to the helper or its effective identity, not to project code.

Practical impact: the user can work normally in Desktop for analysis, review, and compatible tests, but must switch to CLI for any edit through apply_patch.

The analysis did not inspect or disclose repository content, personal paths, SIDs, credentials, or private data. It would be very useful for Desktop to distinguish a helper launch/authorization failure explicitly from a workspace write failure.