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.
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_patchlauncher that directly invokes an AppX-packagedcodex.exeunderC:\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.tomlexpansion, 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-patchThe 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_patchhelper.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:
26.803.10989.0codex-cli 0.147.0x86_64-pc-windows-msvcMicrosoft Windows NT 10.0.26200.0 x64The 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:
helper executable inaccessiblewith the relevant Windows error code, rather than presenting them as a repository write failure or indefinite patch stall.no_fallback.A minimal acceptance test should use
apply_patchon 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 repeatedReconnecting /5attempts for an unchanged large request. A safer client admission design would fingerprint rejected requests, suppress unchanged resubmission until provider reset orRetry-Afterplus 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.