Windows app: uncaught read ENOTCONN during child-process launch with large nested-repository review fan-out

What version of the Codex App are you using?

Windows package OpenAI.Codex_26.901.5280.0_x64. Version obtained from installed package metadata.

What subscription do you have?

Not included in this diagnostic report.

What platform is your computer?

Windows 11 Pro, 10.0.26200, x64. Git for Windows 2.53.0.windows.1. 64 GB physical RAM.

What issue are you seeing?

Codex repeatedly displays “A JavaScript error occurred in the main process”, including after fully quitting and reopening the app:

Uncaught Exception:
Error: read ENOTCONN
    at tryReadStart (node:net:921:20)
    at Socket._read (node:net:936:5)
    at Readable.read (node:internal/streams/readable:741:12)
    at Socket.read (node:net:990:39)
    at new Socket (node:net:630:12)
    at Object.Socket (node:net:486:41)
    at createSocket (node:internal/child_process:337:14)
    at ChildProcess.spawn (node:internal/child_process:492:23)
    at spawn (node:child_process:827:9)
    at jz (<installed Codex app resources; remainder clipped in dialog>)

Read-only inspection of the installed JavaScript found jz launching child processes with stdout/stderr pipes. The exact failing child command and cause of the disconnected pipe remain unconfirmed.

What steps can reproduce the bug?

Observed environment, not a minimal reproduction:

1. Use a large umbrella folder as the Codex workspace. It is itself a Git repository with no tracked files, and contains hundreds of independent repositories, linked worktrees, and artifacts.
2. Open existing tasks and allow the change-review system to inspect the workspace.
3. In two successive sessions, the Git worker logged 990 timed-out commands attributed to source=review_model, requestKind=branch-diff-stats. Many checked nested repository HEADs and shared start times, expiring together after about 60 seconds.
4. The main-process ENOTCONN dialog recurred after an app restart.

Representative redacted log fields:

command="git -c safe.bareRepository=explicit -c core.hooksPath=NUL -c core.fsmonitor= rev-parse --verify --quiet 'HEAD^{commit}'"
cwd="<umbrella-workspace>/<temporary-worktree>"
durationMs=60015 exitCode=null failureReason=timed_out
requestKind=branch-diff-stats source=review_model
subcommand=rev-parse success=false timedOut=true

What is the expected behavior?

Bound nested-repository review concurrency and handle child-process/stdio errors without an uncaught main-process dialog or app instability. Ideally the error and failed child command should be recorded in diagnostics.

Additional information

• An earlier, separate resource buildup involved about 4,650 detached Git file-monitor processes using roughly 170 GiB of private memory. Disabling global core.fsmonitor and stopping those monitors eliminated that buildup, but the ENOTCONN dialog still recurred afterward with zero monitors and available RAM.
• The popup text was not found in the desktop logs, and a recurrence did not create a new Crashpad report. Absence of a new dump is therefore not evidence that the popup has stopped.
• A local mitigation was to add /*/ to the outer repository's .git/info/exclude, excluding child directories from umbrella change tracking while preserving each nested repository's own Git behavior.
• After that change, an outer untracked-file scan completed in about 65 ms. The next app session had zero logged Git timeouts during the initial observation window, compared with 990 in each prior session. This is a workload mitigation, not proof that the underlying runtime defect is fixed.
• No app binaries were modified. Paths, account identifiers, task identifiers, project names, and private repository URLs have been omitted.

Start by reproducing the large nested-repository review fan-out and inspect the installed JavaScript around jz and the node:child_process spawn path. Trace the branch-diff-stats review_model commands and their stdout/stderr pipes, then verify that bounded concurrency and child-process errors avoid an uncaught main-process dialog and are recorded in diagnostics.