Possible SOLUTION of VSCode codex extension of openai.chatgpt-26.623.81905 with apply_patch & codex-windows-sandbox-setup.exe bug (Specified module could not be found.)

What version of the IDE extension are you using?

26.623.81905

What subscription do you have?

GPT Plus

Which IDE are you using?

VS Code

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

It is occured that a Windows Codex sandbox failure when using apply_patch from the VS Code Codex extension.
The issue appears when VS Code is configured to use a local HTTP proxy, for example: http://127.0.0.1:7897

The Codex extension can connect successfully through this proxy, but Codex appears to _pass proxy-related environment variables into its Windows sandbox/apply_patch subprocesses_ ,then

Codex writes this proxy port into: %USERPROFILE%\.codex\.sandbox\setup_marker.json, andd changes the options "proxy_ports": [7897]

After that, apply_patch update/delete operations fail with the Windows sandbox helper error: windows sandbox failed:orchestrator_helper_launch_canceled: ShellExecuteExW failed to launch setup helper: 1223
Sometimes Windows also shows a modal dialog for: codex-windows-sandbox-setup.exe The specified module could not be found.
A wired thing is that add options could be done successfully but before it has done windows still showed alert.

The bug seems related to the native Windows sandbox / filesystem helper path used by apply_patch.

What steps can reproduce the bug?

1. On Windows, configure VS Code to use a local proxy:

{
  "http.proxy": "http://127.0.0.1:7897",
  "http.proxySupport": "on"
}

1. Open a local workspace in VS Code.

Open the Codex extension and use official ChatGPT/Codex login.

1. Confirm that Codex process environment includes proxy variables:

HTTP_PROXY=http://127.0.0.1:7897
HTTPS_PROXY=http://127.0.0.1:7897

1. Comfirm that Codex write this into: %USERPROFILE%\.codex\.sandbox\setup_marker.json

example for the bad state:

{
  "version": 5,
  "offline_username": "CodexSandboxOffline",
  "online_username": "CodexSandboxOnline",
  "proxy_ports": [7897],
  "allow_local_binding": false,
  "read_roots": [],
  "write_roots": []
}

1. Codex run an apply_patch add-file operation:

*** Begin Patch
*** Add File: _codex_apply_patch_test.tmp
+apply patch test
*** End Patch

This may succeed, but has the alert of module not find

1. Then run an apply_patch update operation:

*** Begin Patch
*** Update File: _codex_apply_patch_test.tmp
@@
-apply patch test
+apply patch test updated
*** End Patch

Actual result:

apply_patch verification failed: Failed to read file to update ...
fs sandbox helper failed with status exit code: 1:
windows sandbox failed: orchestrator_helper_launch_canceled:
ShellExecuteExW failed to launch setup helper: 1223

1. Delete operations can also fail similarly:

*** Begin Patch
*** Delete File: _codex_apply_patch_test.tmp
*** End Patch

What is the expected behavior?

apply_patch should work consistently for add, update, and delete operations inside the workspace.
Expected behavior:

Add File: success
Update File: success
Delete File: success

The Windows sandbox helper should not show an OS modal dialog.
If sandbox setup fails, Codex should return a structured error message without interrupting the user with a Windows dialog.
VS Code proxy configuration should not cause apply_patch filesystem operations to fail.

Additional information

I tested several workarounds.

1. Confirmed failure condition

When setup_marker.json contains: "proxy_ports": [7897]
then:

apply_patch Add File: succeeds
apply_patch Update File: fails with 1223
apply_patch Delete File: fails with 1223

1. Confirmed working condition

After preventing Codex subprocesses from inheriting proxy environment variables, and after restarting VS Code/Codex, setup_marker.json remains:"proxy_ports": []
Then all three operations succeed:

apply_patch Add File: success
apply_patch Update File: success
apply_patch Delete File: success

Things tried that did not fully fix it

• Reinstalling the VS Code Codex extension.
• Disabling Windows Defender temporarily.
• Running VS Code as Administrator.
• Manually running codex-windows-sandbox-setup.exe.
• Clearing setup_marker.json manually without preventing proxy env inheritance.
• Switching:

[windows]
sandbox = "unelevated"

• Editing the temporary apply_patch.bat wrapper to clear proxy environment variables before launching codex.exe.

_The reliable fix required changing Codex config and restarting._

Possible Solution / Workaround

The successful workaround was to configure Codex not to pass proxy environment variables to subprocesses.

1. Edit %USERPROFILE%\.codex\config.toml
2. Add the following content into config

[shell_environment_policy]
inherit = "all"
exclude = ["HTTP_PROXY", "HTTPS_PROXY", "http_proxy", "https_proxy"]

1. Ensure %USERPROFILE%\.codex\.sandbox\setup_marker.json contains "proxy_ports": [], then restart VSCode/Codex
2. After restart, verify:

(1) Codex process environment no longer exposes:

HTTP_PROXY
HTTPS_PROXY
http_proxy
https_proxy

(2) setup_marker.json remains "proxy_ports": []
(3) apply_patch add/update/delete operations all succeed.

Suggested upstream fix

Codex should avoid letting editor-level proxy settings break Windows filesystem sandbox operations.
Possible upstream fixes:

1. Do not use HTTP_PROXY / HTTPS_PROXY inherited from VS Code to populate Windows sandbox proxy_ports unless sandboxed command network access actually requires it.
2. Ensure shell_environment_policy.exclude is applied before Windows sandbox setup decides whether proxy/firewall setup is needed.
3. Do not show a Windows modal dialog if codex-windows-sandbox-setup.exe fails. Return a structured Codex error instead.
4. Make apply_patch filesystem operations independent from network proxy sandbox setup when operating only inside the workspace.
5. If proxy ports are stale or unsupported, fail gracefully and continue filesystem-only operations where safe.