Codex Desktop on Windows: MSVC cl.exe remains suspended under MSBuild Tracker; TrackFileAccess=false bypasses the failure

Open 💬 0 comments Opened Aug 14, 2026 by Kuzjayo

What issue are you seeing?

On Windows, MSVC builds launched from Codex Desktop's Work execution environment can hang after MSBuild reaches the compiler.

This is not a normal slow build.

In the affected runs, the observed process chain was:

CMake/MSBuild → Tracker.exe → cl.exe

Process inspection showed that the affected cl.exe process was created successfully but remained suspended with:

one thread;
Suspend Count = 1;
State = Wait:Suspended;
User Time = 0;
Kernel Time = 0;
no compiler or linker diagnostic;
no further build progress.

Process inspection also showed Tracker.exe as the parent of the affected cl.exe.

A controlled workaround strongly localizes the failure to the MSBuild file-tracking path.

For the affected Codex Windows process tree, setting process-scoped:

TrackFileAccess=false

and, for the outer build, additionally passing:

/p:TrackFileAccess=false

allows the same Visual Studio/MSVC CMake path to proceed without leaving cl.exe suspended.

This failure has been observed on the affected Codex Windows execution host. The same canonical project configuration is not proven defective and has been buildable from normal developer environments outside the affected Codex execution path.

I am not claiming that the exact internal implementation root cause is proven, but the observed process state and controlled workaround strongly associate the failure with the MSBuild Tracker / file-access tracking path.

What steps can reproduce the bug?

Environment:

Windows 11 Pro 25H2 x64, build 26200
Codex Desktop on Windows (Work execution environment)
Visual Studio 2022 / MSVC
CMake
C++20 / Qt project

The issue is reproducible on the affected Codex Windows host. I cannot claim that every Codex Windows environment will reproduce it.

Observed sequence:

Launch a Visual Studio/MSVC CMake build from the Codex Windows execution environment.

Example shape:

cmake --build <build-dir> --config Debug --target <target>

On an affected run, the build stops making progress after MSBuild has reached the compiler.

Inspect the process tree.

The observed process path is:

CMake/MSBuild
→ Tracker.exe
→ cl.exe

Process Monitor also captured successful creation of the MSVC compiler process:

Operation = Process Create

Result = SUCCESS

Inspect the affected cl.exe.

Observed state:

one compiler thread;
Suspend Count = 1;
State = Wait:Suspended;
User Time = 0;
Kernel Time = 0;
no compiler or linker diagnostic;
waiting does not make the build progress.

Stop only the process tree created by that build.

Rerun the Visual Studio/MSVC CMake operation while setting the following only for the launched process tree:

TrackFileAccess=false

For an outer cmake --build, also pass:

/p:TrackFileAccess=false

Example PowerShell shape:

$oldTrackFileAccess = $env:TrackFileAccess

try {
$env:TrackFileAccess = 'false'

cmake --build <build-dir> --config Debug
--target <target> `
-- /m:1 /p:TrackFileAccess=false
}
finally {
if ($null -eq $oldTrackFileAccess) {
Remove-Item Env:TrackFileAccess -ErrorAction SilentlyContinue
}
else {
$env:TrackFileAccess = $oldTrackFileAccess
}
}

The process-scoped environment value is required so that nested CMake operations such as try_compile and CheckIPOSupported, their nested MSBuild processes, and cl.exe inherit the setting.

Passing only /p:TrackFileAccess=false to the outer build does not cover those nested CMake/MSBuild process trees.

Controlled results with the process-tree workaround:

isolated CheckIPOSupported probe: PASS, exit code 0, 4.333 s, no suspended cl.exe;
cmake --preset release-vs2022: PASS, exit code 0, 29.903 s, no suspended cl.exe;
cmake --build --preset build-release-vs2022 --target NeuralScioAI -- /p:TrackFileAccess=false with the same process environment: PASS, exit code 0, 5.196 s, NeuralScioAI.exe produced, no suspended cl.exe.

The environment override was restored after each controlled command.

No Machine/User environment variables, registry settings, CMake project configuration, CMake presets, CI configuration, or IDE settings were changed as part of the workaround.

What is the expected behavior?

Visual Studio/MSVC builds launched through Codex Desktop on Windows should behave like ordinary MSVC builds and should not leave compiler processes suspended indefinitely.

Once MSBuild successfully creates cl.exe, the compiler should either:

execute normally and make compilation progress;
terminate with an actionable compiler/toolchain diagnostic; or
be terminated cleanly if the parent operation fails.

It should not remain alive with:

Suspend Count = 1;
State = Wait:Suspended;
zero user/kernel CPU time;

while the parent build waits indefinitely without reporting an error.

If the Codex Windows execution environment is incompatible with the relevant MSBuild Tracker / file-access tracking behavior, Codex should either:

configure the execution environment so MSBuild tracking works normally;
bypass the incompatible tracking path when appropriate; or
detect this suspended/no-progress compiler state and return an actionable diagnostic instead of waiting indefinitely.

Users should not need to manually set TrackFileAccess=false to make an otherwise valid Visual Studio/MSVC CMake build proceed.

Additional information

This occurs in the same Codex-on-Windows / MSBuild execution area as #19546 and #28022, but it is a distinct failure mode.

#19546 and #28022 concern the Codex Windows process environment containing both:

Path

and:

PATH

which can cause MSBuild to fail before normal C++ compilation with:

MSB6001

and an exception similar to:

Item has already been added. Key in dictionary: 'Path' Key being added: 'PATH'

In this report, that environment-key problem has already been avoided.

The failure happens later:

CMake/MSBuild
→ Tracker.exe
→ cl.exe successfully created
→ compiler thread remains suspended
→ Suspend Count = 1
→ Wait:Suspended
→ zero user/kernel CPU time
→ no compiler/linker diagnostic
→ build makes no further progress

Process inspection showed Tracker.exe as the parent of the affected cl.exe.

The controlled workaround also distinguishes two propagation boundaries:

/p:TrackFileAccess=false applies to the outer native MSBuild invocation;
process-scoped TrackFileAccess=false is inherited by nested CMake / try_compile / CheckIPOSupported operations and their nested MSBuild/compiler processes.

The original outer-build-only workaround did not cover nested CMake/MSBuild operations.

With the process-tree environment override plus the explicit outer MSBuild property, controlled validation produced:

isolated CheckIPOSupported: PASS, exit 0, 4.333 s, no suspended cl.exe;
release configure: PASS, exit 0, 29.903 s, no suspended cl.exe;
NeuralScioAI MSVC build: PASS, exit 0, 5.196 s, executable produced, no suspended cl.exe.

The same canonical project configuration is not proven defective; the issue has been isolated to the affected Codex Windows execution host rather than persisted into project configuration.

The workaround is intentionally process-scoped. It is not applied through setx, Machine/User environment variables, registry, CMakeLists.txt, CMakePresets.json, CI, or IDE settings.

I am not claiming that the precise internal cause inside MSBuild/Codex has been proven. However, the combination of:

Tracker.exe being the parent of the affected compiler;
the compiler being created but remaining in Wait:Suspended;
Suspend Count = 1;
zero user/kernel CPU time;
and the failure disappearing when MSBuild file-access tracking is disabled;

strongly localizes the problem to the MSBuild Tracker / file-access tracking path in the affected Codex Windows execution environment.

Related issues:

#19546 — duplicate Path / PATH environment keys cause MSBuild to fail before compilation.
#28022 — MSBuild regression involving duplicate PATH / Path.

This report is specifically about the post-PATH-fix Tracker / suspended-cl.exe failure.

View original on GitHub ↗