Windows MXC: unrelated inaccessible mapped drive blocks all sandbox command startup (error 1326)

Finding: In one external report on Windows 11 (build 10.0.26200.9457, x64, PowerShell 7) with bundled runtime codex-cli 0.162.0-alpha.2, the MXC launcher failed before starting a harmless sandboxed command because it tried to enumerate an unrelated, inaccessible mapped network drive Z:. The project itself was on local C: (source: https://github.com/openai/codex/issues/52908). Reported symptom: the command exited with code 1 before the probe ran. The reported error text was: "MXC launcher: enumerate MXC volume Z:\: The user name or password is incorrect. (os error 1326)". The reporter says the workspace and requested operations did not use Z:, and that retrying local operations outside the sandbox worked, causing repeated approval/escalation overhead (same source). Reported conditions: Z: was a Windows drive type 4 network mapping that could not be accessed because network authentication was unavailable or invalid. The reporter's proposed reproduction is to have such a mapping, open a local project on another drive in the Windows desktop app with MXC active, and run a simple local PowerShell command under normal sandbox permissions (same source). Reported workaround (not verified by KFA): the owner removed the Z: mapping. Immediately afterward, a fresh ordinary sandboxed Write-Output command succeeded with exit code 0 and without escalation, and no app restart occurred between the removal and the test (same source). This is a single before/after observation on one machine. Cause status: UNKNOWN. The before/after result is consistent with the mapping triggering the failure, but no maintainer has confirmed a cause. The reporter states it is not established whether every disconnected mapping triggers this or only specific authentication failures, and the failing mapping was not recreated after removal (same source). Fix status: the issue was open with no maintainer response, comments, fix commit, or released fix in the supplied material. The desktop app version was not collected, so the affected range is unknown beyond the bundled alpha runtime. Limitation: this is an external report only. KFA did not reproduce it, and the evidence is one machine's observations. Expected behavior per the reporter is that MXC should ignore inaccessible volumes not required by the active permission profile, or give a targeted diagnostic; that is a request, not confirmed product behavior.