[Windows Codex App] Dart build_runner stalls mid-build but completes in user's terminal

Open 💬 2 comments Opened Aug 20, 2026 by SonderXiaoming

What version of the Codex App are you using?

The current Codex desktop app on Windows. The agent was unable to retrieve the About-dialog version from the affected session because a diagnostic command also failed to return.

What platform is your computer?

Windows x64, using PowerShell in a local workspace.

What issue are you seeing?

A longer, multi-stage Dart code-generation command stalls when launched through the Codex App command runner, while the same command completes quickly when the user runs it directly in their own PowerShell terminal.

Command:

cd D:\flutter\misora_note
dart run build_runner build --delete-conflicting-outputs

The problem reproduced in both non-interactive (pipe) and PTY execution.

First run (pipe mode):

Build progressed through freezed and json_serializable.
drift_dev reached approximately 5 skipped, 1 output, 5 same.
No further output was returned for several minutes.
Only a nearly idle Dart process remained (about 0.25 seconds accumulated CPU at inspection time).
lib/core/db/database.g.dart retained its old timestamp and size, so the build had not completed.
The process had to be terminated manually.

Second run (PTY mode):

Live progress was returned correctly at first.
drift_dev advanced further, to approximately 74 skipped, 5 output, 44 same.
Output then stopped again.
The remaining Dart process was nearly idle.
database.g.dart was still unchanged.
Ctrl+C was required.

The user reports that running the exact same command directly in their own terminal does not take this long and completes normally.

This appears to be more specific than a general shell failure: ordinary short PowerShell commands in the same Codex session work, but this longer Dart/build_runner process becomes dormant partway through when managed by Codex.

What steps can reproduce the bug?

Open a Flutter/Dart workspace with Drift and build_runner in the Windows Codex App.
Make a change that requires regenerating a large Drift database file.
Ask Codex to run:

``powershell dart run build_runner build --delete-conflicting-outputs``

Observe normal progress through freezed, json_serializable, and part of drift_dev.
Continue polling the unified exec session.
Observe that output stops, the Dart process becomes nearly idle, and the expected generated file remains unchanged.
Cancel the process.
Run the same command directly in the user's PowerShell terminal; it completes normally.

What is the expected behavior?

Codex App should keep the child process alive and connected until build_runner exits, continuously deliver progress/output, and return its exit code. If the process or transport fails, the command should fail promptly with a diagnostic instead of remaining indefinitely in a running state.

Additional information

The generator emitted this warning before stalling:

SDK language version 3.10.0 is newer than analyzer language version 3.9.0.
Run flutter packages upgrade.

That warning may affect build performance, but it does not explain why the same project command completes in the user's direct terminal.

Possibly related, but not exact duplicates:

#20874 — completed Windows command output can be dropped and the tool can keep waiting
#39574 — Windows exec_command can hang for trivial commands

This report differs because short commands remain usable, the failure occurs partway through a longer multi-stage child process, and the expected generated artifact confirms that the build itself did not finish.

View original on GitHub ↗

2 Comments

MilkyWay008 · 7 days ago

The build_runner dying only when launched through the Codex App runner, but finishing fine in your own PowerShell, points at the spawn env rather than the build itself, the piped/PTY child staying near idle (~0.25s CPU) matches that. First run flutter packages upgrade to clear that SDK 3.10 vs analyzer 3.9.0 mismatch warning, then try dart run build_runner build --delete-conflicting-outputs --verbose inside the Codex runner and see if it still halts at drift_dev, that'll tell you if it's the runner or the build. Worth killing any orphan dart/build_runner processes before retrying too, Windows likes to wedge them.

SonderXiaoming · 7 days ago

Thanks for the suggestions. I tried all three steps, but unfortunately the issue still reproduces.

First, I terminated the orphaned Dart/build_runner processes. I then ran flutter packages upgrade. This completed only when the command was allowed to run outside the Codex restricted environment. It upgraded analyzer from 7.7.1 to 8.4.1 and removed the SDK/analyzer language-version warning.

I then retried:

dart run build_runner build --delete-conflicting-outputs --verbose

There appear to be two separate problems:

In the normal Codex App command environment, the command did not reach the Dart VM. dart.bat repeatedly tried to acquire/write:

C:\flutter\bin\cache\flutter.bat.lock

Because that write was denied, the batch script stayed in its lock retry loop without producing an error. Bypassing dart.bat and invoking dart.exe directly instead failed while spawning dartaotruntime:

CreateFile failed 5
ProcessException: Access is denied.

In unrestricted execution, the command could start. The upgraded build_runner 2.15.1 initially failed during AOT builder compilation because the dependency graph contained build hooks:

'dart compile' does not support build hooks, use 'dart build' instead.

Adding --force-jit allowed it to proceed through freezed and json_serializable, but it still became dormant during drift_dev, at approximately:

5 skipped, 6 output

Both Dart processes showed no CPU increase during repeated sampling, and lib/core/db/database.g.dart remained unchanged.

So clearing the analyzer mismatch did not resolve the original stall. The additional evidence still points to the Codex Windows command runner/restricted process environment rather than the Drift build itself.