MXC blocks browser tools and shell commands when an unrelated network drive is disconnected #51665

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   windows-osIssues related to Codex on Windows systemsIssues related to Codex on Windows systems

   sandboxIssues related to permissions or sandboxingIssues related to permissions or sandboxing

   browser

   on Oct 7, 2026
2. github-actions commented on Oct 7, 2026

   

   github-actionsBot

   on Oct 7, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • MXC fails before command launch when an unrelated BitLocker volume is locked #50915

   Powered by Codex Action
3. Phantomthedog commented on Oct 11, 2026

   

   Phantomthedog

   on Oct 11, 2026 – with ChatGPT Codex Connector

   More actions

   Confirmed the same failure on Codex Desktop 26.1007.2314.0 with bundled CLI 0.162.0-alpha.17.2. Native execution stalled before the requested shell started, then returned the MXC volume enumeration error with Windows error 64.

   Two mapped SMB drives pointed to a network that was no longer reachable. Removing the stale drive mappings, their remembered reconnect entries, and a remaining SMB mapping record restored native PowerShell, CMD, and Node execution without restarting Codex. Local file access also succeeded.

   This provides a workaround for this instance. MXC should still tolerate an unavailable drive unrelated to the workspace.

   A PowerShell InitializeDefaultDrives warning remains, although commands and local file access now succeed; its cause has not been established.
4. volkhen commented on Oct 12, 2026

   

   volkhen

   on Oct 12, 2026

   More actions

   Additional confirmation — Windows error 1265
   I encountered the same issue with ChatGPT/Codex Desktop version 26.1007.21434.
   An unrelated, disconnected mapped network drive prevented Codex from executing even basic commands in local projects.
   The MXC launcher reported:
   MXC launcher: enumerate MXC volume X:
   Windows authentication/domain controller failure
   (os error 1265)

   The affected projects were located on a local drive and had no relationship to the network mapping.
   Resolution:

   1. Confirmed that the mapped drive was disconnected and inaccessible.
   2. Removed the unused mapping using net use X: /delete.
   3. Retested Codex in two unrelated local projects.
   4. Both projects immediately executed commands successfully.
      No project files or security settings were modified.
      This confirms that error 1265 is another failure mode associated with MXC enumerating unrelated, inaccessible network drives.
      The workaround was successful, but MXC should ideally handle unavailable network volumes without preventing execution in unrelated local workspaces.
5. hayateppp commented on Oct 19, 2026

   

   hayateppp

   on Oct 19, 2026 – with ChatGPT Codex Connector

   Last edited by hayateppp

   More actions

   Additional diagnosis and locally verified fix for Windows error 64.

   Environment:

   • Codex desktop package: 26.1013.4894.0; app internal version: 26.1013.40934.
   • Bundled CLI: 0.163.0-alpha.10.2.
   • Matching public source: tag rust-v0.163.0-alpha.10.2, commit 4ebc485ca321243727539187169425fcf972f2c4.

   The affected existing chat fails before PowerShell starts:

   MXC launcher: enumerate MXC volume <unrelated mapped drive>: The specified network name is no longer available. (os error 64)
   

   The workspace is on an accessible local drive. With [windows] allow_mxc = false in requirements.toml and sandbox = "elevated" in user config, a newly created chat can execute commands, while the existing affected chat continues to hit MXC. That chat-to-chat difference is observed; its persistence mechanism has not been established.

   In codex-rs/mxc-sandbox/src/policy.rs, inaccessible_volume() does not recognize ERROR_NETNAME_DELETED (64). This error was verified on this Windows/Rust environment not to be covered by the existing ErrorKind checks. Proposed minimal change:

    use windows_sys::Win32::Foundation::ERROR_DEVICE_NOT_CONNECTED;
   +use windows_sys::Win32::Foundation::ERROR_NETNAME_DELETED;
    ...
   - Some(ERROR_NOT_READY | ERROR_DEVICE_NOT_CONNECTED | ERROR_BAD_NETPATH)
   + Some(ERROR_NOT_READY | ERROR_DEVICE_NOT_CONNECTED | ERROR_BAD_NETPATH | ERROR_NETNAME_DELETED)

   Validation completed:

   1. Extracted the actual original and changed predicate from the pinned source and compiled Windows Rust tests using constants from the installed Windows SDK. Original: the error-64 assertion fails. Changed: it passes; ERROR_INVALID_PARAMETER remains unrecognized.
   2. Added the same two regression tests inside the actual policy module and ran:

   cargo test --locked -p codex-mxc-sandbox volume_error_tests -- --nocapture
   test result: ok. 2 passed; 0 failed; 20 filtered out
   

   Toolchain: Rust 1.95.0, x86_64-pc-windows-msvc.

   A full CLI build has now succeeded: cargo build --locked --offline -p codex-cli --bin codex (dev profile, debug symbols disabled). The resulting Windows executable reports codex-cli 0.163.0-alpha.10.2; both --version and app-server --help return exit code 0. The installed CLI's SHA-256 remains unchanged; the candidate has not been activated in the app.

   Build reproducibility note: the release tag's lock file initially contained local workspace versions 0.0.0. Regenerating it normalized those to the release version; all external dependency versions and checksums were programmatically verified unchanged. This is a tested predicate-level fix candidate, not a claim of completed end-to-end MXC repair. No mapped drive was accessed, disconnected, or changed during this investigation; actual MXC launch was deliberately not used for validation because of the user's no-access constraint.

   User impact: investigating this Codex failure consumed usage budget; the user reports reaching the five-hour limit and spending a personal rate-limit reset entitlement to continue debugging.

   Please incorporate the appropriate error-64 handling and regression coverage into an upcoming Windows Codex update so users do not need to rebuild Codex or remove unrelated drive mappings.