Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

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

Open Beginner friendly
  • Is something wrong?
#50,915 0 comments 1 reaction 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
76/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
rust
Domain
operating-systems

Research direction

Start in codex-rs/mxc-sandbox/src/policy.rs by reading inaccessible_volume() and the generated logical-volume expansion path. Add a Windows regression test using the suggested io::Error::from_raw_os_error(0x80310000u32 as i32) classification, and check that an unrelated filesystem error remains fatal. Done means generated expansion skips the locked volume while explicit path grants still fail closed.

Written by the indexing model from the issue text.

Description

app bug sandbox windows-os

Summary

On Windows, Codex's MXC sandbox fails before launching any child process when an unrelated BitLocker data volume is present but locked.

The project/workspace is on another drive and does not reference the locked volume.

Environment

  • Windows 11 build 26200
  • ChatGPT/Codex Desktop: 26.930.3930.0
  • bundled codex-cli: 0.160.0
  • Windows sandbox backend: MXC

Reproduction

With an unrelated BitLocker data volume locked (observed as E:\), run any trivial command through MXC, for example a command that only writes a fixed string from a workspace on another drive.

The command never starts. MXC exits first with:

MXC launcher: enumerate MXC volume E:\: This drive is locked by BitLocker Drive Encryption. You must unlock this drive from Control Panel. (os error -2144272384)

The signed error value corresponds to 0x80310000 / FVE_E_LOCKED_VOLUME.

Root cause

In codex-rs/mxc-sandbox/src/policy.rs, a permission profile containing :root is materialized across logical volume roots returned by GetLogicalDrives().

The generated root for the locked BitLocker volume is probed with read_dir(). The resulting FVE_E_LOCKED_VOLUME error is not classified by inaccessible_volume() as an unavailable volume, so the failure falls through to PolicyError::EnumerateVolume and MXC exits before child-process creation.

Current upstream appears to retain the same omission.

A named MXC permission profile without :root avoids the failure on the same host, which isolates the trigger to generated root-volume expansion rather than general MXC process launch.

Expected behavior

An unrelated locked BitLocker volume should be treated like another unavailable logical volume during generated volume-root expansion and should not prevent commands scoped to accessible volumes from launching.

Explicitly requested paths should continue to fail closed.

Suggested fix

Treat FVE_E_LOCKED_VOLUME (0x80310000) as an inaccessible/unavailable volume in the generated logical-volume expansion path.

A minimal Windows regression test could assert that:

io::Error::from_raw_os_error(0x80310000u32 as i32)

is classified as an inaccessible volume, while an unrelated filesystem error remains fatal.

This should preserve the existing fail-closed behavior for explicit path grants while preventing an unrelated locked BitLocker volume from breaking all MXC command execution.

Dominant language
Rust
Stars
127k
Forks
19.9k
Avg merge
1m
Merged PRs (30d)
994

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from openai/codex

All issues in openai/codex

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.