Codex in Windows ChatGPT app: apply_patch takes 117s on localized Google Drive workspace vs 0.1s in Full Access

Start by comparing the Windows sandbox behavior in the desktop app with the repeated <CODEX_HOME>\.sandbox-bin\codex.exe --codex-run-as-fs-helper launches recorded during apply_patch. Reproduce on a Google Drive streamed FAT32 workspace using the elevated and unelevated settings, then compare the related issues #21117, #14585, #13378, and #17179. Done means identifying the retry or compatibility cause and defining a prompt, fast behavior for this filesystem.

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

26.707.12708.0 (Microsoft Store package, ARM64)

What subscription do you have?

Pro

What platform is your computer?

Microsoft Windows NT 10.0.26200.0, 64-bit (Windows 11 Pro, ARM64)

What issue are you seeing?

Summary

This report concerns Codex tasks inside the Windows ChatGPT/Codex desktop app, not a standalone Codex CLI session.

On a Google Drive for desktop localized workspace (virtual G:\My Drive\<project> volume), the elevated Windows sandbox cannot apply ACLs and fails before commands run. Switching to the documented unelevated fallback lets commands start, but the built-in apply_patch path becomes extremely slow.

A controlled one-line patch test in the same app task measured:

• workspace-write + windows.sandbox = "unelevated" + auto-review: 117.480 seconds
• Danger Full Access: 0.099 seconds

The restricted-mode patch was approximately 1,187x slower. The same temporary line was added and then removed successfully.

Errors and logs

With the elevated Windows sandbox:

windows sandbox failed: helper_unknown_error: setup refresh had errors

The sandbox log identifies the underlying failure:

write ACE grant failed on G:\My Drive\<project>: SetNamedSecurityInfoW failed: 87
setup refresh completed with errors
setup error: setup refresh had errors

After switching to unelevated mode and restarting the app, the setup-refresh failures stopped. However, during the 117-second apply_patch call, the log showed repeated launches of:

<CODEX_HOME>\.sandbox-bin\codex.exe --codex-run-as-fs-helper

These launches occurred at roughly 20–21 second intervals.

Filesystem details

fsutil fsinfo volumeinfo G: reports the streamed Google Drive volume as:

• File System Name: FAT32
• Read/write
• Supports remote storage

The virtual volume does not accept the Windows ACL changes required by the elevated sandbox. Marking streamed files available offline does not change the filesystem interface.

Diagnostic component version

The app bundles codex-cli 0.144.5 internally. That version is included only as diagnostic information; the affected surface is the Windows ChatGPT/Codex desktop app.

What steps can reproduce the bug?

1. On Windows 11 ARM64, open a Codex task inside the Windows ChatGPT/Codex desktop app.
2. Use a workspace located on a Google Drive for desktop volume such as G:\My Drive\<project>.
3. Use restricted/workspace-write permissions with approvals_reviewer = "auto_review".
4. With [windows] sandbox = "elevated", run any simple command. Sandbox setup attempts to grant an ACE on the workspace and fails with Windows error 87.
5. Change the setting to [windows] sandbox = "unelevated", fully restart the desktop app, and reopen the task.
6. Apply a one-line edit using the built-in apply_patch tool and time only the patch call.
7. Observe repeated --codex-run-as-fs-helper launches at approximately 20-second intervals. In my controlled test the patch completed after 117.480 seconds.
8. Switch the same task to Danger Full Access.
9. Remove exactly the same temporary line with apply_patch. In my controlled test this completed in 0.099 seconds.

No overlapping writes were performed, and the temporary test marker was removed afterward.

What is the expected behavior?

A small built-in apply_patch edit in a workspace that the app labels writable should complete promptly.

If non-ACL filesystems cannot support the native Windows sandbox, the app should either:

• provide a fast, approved fallback for the narrowly scoped patch operation;
• avoid repeated ~20-second filesystem-helper retry cycles; or
• report an immediate actionable incompatibility message.

Auto-review should not turn a one-line patch into a roughly two-minute operation.

Additional information

This may overlap with several existing Windows sandbox issues:

• #21117 — apply_patch sandbox retry can request duplicate approval and hang app-server turns
• #14585 — Windows sandbox ACL/apply_patch failures
• #13378 — Windows sandbox ACL failure on non-system drives and ACL pollution
• #17179 — workspace-write edits fail while Full Access succeeds immediately

The repeated ~20-second helper launches make #21117 appear especially relevant, although this report's underlying workspace is a Google Drive streamed virtual FAT32 volume rather than NTFS.

The app's strict config/doctor checks passed for configuration, authentication, databases, installation, and network. The only doctor failure was the expected noninteractive TERM=dumb terminal-color check, which appears unrelated.