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

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?

1. On Windows, open a fresh Codex App task using a named managed workspace-write permission profile.

2. Give the profile write access only to a synthetic test workspace and temporary directory. Keep network restricted.

3. Confirm that the task can create, read, remove, and prove absence of a harmless file inside the approved workspace.

4. Ask the task to modify another harmless file using the official apply_patch helper.

5. 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.

6. Observe that helper execution stalls or fails with access denied even though direct create/read/remove operations in the target workspace succeed.

7. 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>

8. Observe that the standalone official helper applies the patch successfully under the existing bounded workspace policy.

9. 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:

1. Select an apply-patch executable that is guaranteed to be executable by the intended sandbox identity.
2. Preflight the resolved helper path, existence, executable access, version, architecture, and required companion resources before dispatch.
3. 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.
4. Display the Codex App version, embedded CLI version, standalone CLI version if detected, selected helper path, and helper hash in diagnostics.
5. Preserve the existing bounded filesystem policy; fixing the helper must not require broad filesystem access or ACL weakening.
6. 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.
7. 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.

No source file or test is named. Start by reproducing the Windows AppX launcher failure with --codex-run-as-apply-patch, then compare it with the standalone CLI path under the bounded workspace policy. Done means the App selects an executable accessible to the sandbox and reports helper-launch failures distinctly, with the requested diagnostic details and a harmless apply-patch acceptance test.