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

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?

1. Open a Flutter/Dart workspace with Drift and build_runner in the Windows Codex App.

2. Make a change that requires regenerating a large Drift database file.

3. Ask Codex to run:

   dart run build_runner build --delete-conflicting-outputs
   

4. Observe normal progress through freezed, json_serializable, and part of drift_dev.

5. Continue polling the unified exec session.

6. Observe that output stops, the Dart process becomes nearly idle, and the expected generated file remains unchanged.

7. Cancel the process.

8. 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.

Reproduce the Windows Codex App command-runner case with dart run build_runner build --delete-conflicting-outputs, comparing pipe and PTY execution with the user's direct PowerShell terminal. Start by tracing the unified exec session, child-process lifetime, and output transport around the stall. Done means the command remains connected until exit, continues delivering output, and reports completion or a prompt diagnostic instead of hanging.