Skip to content

Windows 10: sandbox setup helper shows "The specified module could not be found" after updating Codex App #29127

Closed as duplicate
Closed as duplicate
Windows 10: sandbox setup helper shows "The specified module could not be found" after updating Codex App#29127
Labels
appIssues related to the Codex desktop appbugSomething isn't workingsandboxIssues related to permissions or sandboxingwindows-osIssues related to Codex on Windows systems

Description

@fibsion-Pm
fibsion-Pm
opened on Jun 19, 2026

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

26.616.32156

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Microsoft Windows NT 10.0.19045.0 x64 Windows 10 Pro

What issue are you seeing?

After updating and reinstalling the Codex App, Windows intermittently displays an error dialog for:

C:\Program Files\WindowsApps\OpenAI.Codex_26.616.4196.0_x64__2p2nqsd0c76g0\app\resources\codex-windows-sandbox-setup.exe

The Windows error dialog says:

The specified module could not be found.

When this happens, file editing with apply_patch fails. One representative error was:

apply_patch verification failed: Failed to read file to update <PROJECT_ROOT>\src\game_translator\adapters\.codex_acl_apply_patch_probe.txt: fs sandbox helper failed with status exit code: 1: windows sandbox failed: orchestrator_helper_launch_canceled: ShellExecuteExW failed to launch setup helper: 1223

### What steps can reproduce the bug?

The issue is not fully deterministic from a clean installation, but this is the observed sequence:

1. Use Codex App on Windows 10 with the native Windows sandbox.
2. Update/reinstall Codex App to version 26.616.4196.0.
3. Open an existing workspace using `workspace-write`.
4. Ask Codex to create or update a file in a nested project directory using `apply_patch`.
5. Repeat the `apply_patch` operation in the same nested directory.
6. Windows displays a dialog for `codex-windows-sandbox-setup.exe` saying "The specified module could not be found."
7. The patch fails with `orchestrator_helper_launch_canceled` and `ShellExecuteExW ... 1223`.

Originally, the configuration used:
toml
[windows]
sandbox = "elevated"

### What is the expected behavior?

_No response_

### Additional information

Codex App version shown in About Codex: `26.616.32156`
Microsoft Store/AppX package version: `26.616.4196.0`

Activity

  1. fibsion-Pm
    added
    appIssues related to the Codex desktop app
    on Jun 19, 2026
  2. github-actions
    added
    bugSomething isn't working
    windows-osIssues related to Codex on Windows systems
    sandboxIssues related to permissions or sandboxing
    on Jun 19, 2026
  3. fibsion-Pm
    closed this as completedon Jun 19, 2026

  4. github-actions commented on Jun 19, 2026

    @github-actions
    github-actionsBot
    on Jun 19, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  5. fibsion-Pm
    reopened this on Jun 19, 2026

  6. CZH0919 commented on Jun 19, 2026

    @CZH0919
    CZH0919
    on Jun 19, 2026

    I think this is because of .codex.env
    Based on the current evidence, this issue appears to be related to a state mismatch in the Windows elevated sandbox setup after recent Codex updates.

    In my environment, Codex uses a configured proxy and the Windows sandbox state file records a proxy port in its stored sandbox setup marker. However, the newer Codex runtime appears to sometimes compute the desired proxy port list as empty. As a result, the sandbox repeatedly detects an offline firewall configuration mismatch, with logs showing a pattern like:

    offline firewall settings changed (stored_ports=[...], desired_ports=[])

    After that, Codex repeatedly attempts to refresh or relaunch the Windows sandbox setup helper. In the affected versions, this elevated helper launch path can fail with:

    ShellExecuteExW failed to launch setup helper: 1223

    and may also trigger a Windows popup for codex-windows-sandbox-setup.exe saying that the specified module could not be found.

    This would explain why normal shell file operations may still work, why apply_patch can sometimes create a file successfully, and why later edit/delete operations fail. It also explains why the issue can appear after an update without any project-level configuration change.

    So my current hypothesis is:

    Older sandbox state contains a stored proxy/firewall configuration.
    Newer Codex versions calculate a different desired proxy/firewall configuration.
    The elevated Windows sandbox repeatedly decides setup refresh is required.
    The setup helper launch path then fails intermittently or consistently with ShellExecuteExW 1223.
    apply_patch/edit operations fail as a downstream symptom.

  7. CZH0919 commented on Jun 19, 2026

    @CZH0919
    CZH0919
    on Jun 19, 2026

    I think this is because of .codex.env Based on the current evidence, this issue appears to be related to a state mismatch in the Windows elevated sandbox setup after recent Codex updates.

    In my environment, Codex uses a configured proxy and the Windows sandbox state file records a proxy port in its stored sandbox setup marker. However, the newer Codex runtime appears to sometimes compute the desired proxy port list as empty. As a result, the sandbox repeatedly detects an offline firewall configuration mismatch, with logs showing a pattern like:

    offline firewall settings changed (stored_ports=[...], desired_ports=[])

    After that, Codex repeatedly attempts to refresh or relaunch the Windows sandbox setup helper. In the affected versions, this elevated helper launch path can fail with:

    ShellExecuteExW failed to launch setup helper: 1223

    and may also trigger a Windows popup for codex-windows-sandbox-setup.exe saying that the specified module could not be found.

    This would explain why normal shell file operations may still work, why apply_patch can sometimes create a file successfully, and why later edit/delete operations fail. It also explains why the issue can appear after an update without any project-level configuration change.

    So my current hypothesis is:

    Older sandbox state contains a stored proxy/firewall configuration. Newer Codex versions calculate a different desired proxy/firewall configuration. The elevated Windows sandbox repeatedly decides setup refresh is required. The setup helper launch path then fails intermittently or consistently with ShellExecuteExW 1223. apply_patch/edit operations fail as a downstream symptom.

    Open AI should fix this.

  8. VeloxCapPartners commented on Jun 19, 2026

    @VeloxCapPartners
    VeloxCapPartners
    on Jun 19, 2026

    Additional confirmation: this is failing before SSH auth/key selection.
    Version 26.616.32156 • Released Jun 18, 2026

    Inside Codex runner:

    • whoami shows the new sandbox/offline runner account rather than my normal Windows user.
    • ssh -G <user>@<tailnet-host> resolves the host correctly to its Tailnet IP.
    • Test-NetConnection <tailnet-ip> -Port 22:
      • PingSucceeded: True
      • TcpTestSucceeded: False
    • ssh -vvv fails at socket connect:
      • finish_connect - ERROR: async io completed with error: 10013
      • connect to address <tailnet-ip> port 22: Permission denied

    The same target and command works from normal Administrator PowerShell as my regular user.

    Windows Firewall outbound allow rules for TCP/22 to the Tailnet range, OpenSSH, and the Codex app binary did not change the behavior.

    This lines up with my symptoms. In my case the visible failure is not apply_patch/editing, but network access from the Windows Codex sandbox runner.

    Normal PowerShell can SSH to the Tailnet host. Codex tool execution runs under the sandbox/offline runner account. From inside that runner, DNS/Tailnet resolution works and ping succeeds, but TCP/22 fails before SSH auth with Windows socket error 10013.

    I also tried explicit Windows Firewall outbound allow rules for Tailnet TCP/22, OpenSSH, and the Codex app binary; no change.

    Happy to test a reset command if there is a supported way to clear/rebuild the Windows sandbox state.

  9. fibsion-Pm commented on Jun 20, 2026

    @fibsion-Pm
    fibsion-Pm
    on Jun 20, 2026
    Author

    Update: the issue still reproduces after updating Codex

    I updated/reinstalled the Codex Windows app, but the same issue still occurs.

    Environment

    1. OS: Windows 10 Pro x64, build 19045
    2. Subscription: ChatGPT Plus
    3. Previous Codex About version: 26.616.32156
    4. Previous Microsoft Store/AppX package version: 26.616.4196.0
    5. Current Codex About version: 26.616.41845
    6. Current Microsoft Store/AppX package version: 26.616.5445.0
    7. Sandbox configuration:
    [windows]
sandbox = "elevated"

    The currently running executable is located under:

    C:\Program Files\WindowsApps\OpenAI.Codex_26.616.5445.0_x64__2p2nqsd0c76g0\

    Reproduction result

    The same problem was reproduced in two separate workspaces:

    G:\DevProjects\Game
F:\AIs_tools\AI_KnowledgeBase

    Reproduction sequence:

    1. Ask Codex to create a temporary file using apply_patch.
    2. The first patch may report success, and the file may actually be created.
    3. At approximately the same time, Windows displays an error dialog for codex-windows-sandbox-setup.exe.
    4. The dialog says:
    The specified module could not be found.
    1. A subsequent apply_patch operation may fail with:
    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

    The Windows dialog can therefore appear even when the first patch reports success.

    Additional observation

    A direct PowerShell operation on the same temporary file succeeds:

    Remove-Item -LiteralPath "<workspace>\.codex_project_repro_probe.txt" -Force

    The target file is inside the writable workspace, and its owner and ACL are valid.

    This suggests that the failure is specific to the apply_patch / Windows sandbox setup-helper path, rather than a general inability to write to the workspace.

    The sandbox log also repeatedly contained entries similar to:

    sandbox setup required: offline firewall settings changed
(stored_ports=[7890], desired_ports=[])

    The behavior is intermittent. Some later sandbox setup refreshes complete successfully, but the popup and apply_patch failure can still return.

    Expected behavior

    apply_patch should create, update, and delete files inside an authorized workspace without displaying a failing setup-helper dialog.

    If the Windows sandbox configuration needs to be refreshed, codex-windows-sandbox-setup.exe should start successfully and should not cancel the patch operation.

    Updating from package version 26.616.4196.0 to 26.616.5445.0, reinstalling Codex, and using sandbox = "elevated" did not resolve the issue.

  10. loria93 commented on Jun 24, 2026

    @loria93
    loria93
    on Jun 24, 2026

    My codex had the same problem. And I do think that could burn your tokens at a horrible speed...one request burned all my 5-hour token with hundreds of Window alerts...and tens of retries and workarounds.

  11. loria93 commented on Jun 24, 2026

    @loria93
    loria93
    on Jun 24, 2026

    BTW, although Codex CLI has the same problem, it doesn't produce aleart windows, at least.

  12. Luo-Hao-Yu commented on Jul 8, 2026

    @Luo-Hao-Yu
    Luo-Hao-Yu
    on Jul 8, 2026
    1. Check whether the following configuration appears in the codex/config.toml file: [windows] sandbox = "elevated"
    2. If it does exist, please change it to [windows] sandbox = "unelevated".
  13. etraut-openai
    closed this as a duplicateof Windows app 26.616.3309.0: native sandbox setup helper fails with “The specified module could not be found #28982 on Aug 6, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbugSomething isn't workingsandboxIssues related to permissions or sandboxingwindows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions