Codex-generated Windows launcher freezes machine when copied backend exe is used

Open 💬 0 comments Opened Jun 18, 2026 by AHzhangwen

What version of the Codex App are you using (From “About Codex” dialog)?

Codex App 26.611.8604.0 Package: OpenAI.Codex_26.611.8604.0_x64__2p2nqsd0c76g0

What subscription do you have?

ChatGPT Pro 200$

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64 Windows 11 Pro 64-bit, build 26200

What issue are you seeing?

Severity: High

Codex generated a Windows manual-test launcher that points to copied backend executable directories. Running the generated launcher can make the Windows desktop severely sluggish/unusable, but the backend never becomes available.

The launcher prints that startup is running, then the backend log stops at Starting backend.... The expected backend process does not listen on 127.0.0.1:18120.

This appears to be a Codex-generated artifact regression: an earlier hardlink-safe backend package worked, but later generated packages q344/q345 point back to copied backend directories, even though the same output root contains a safety note saying copied backend executables can hang on this machine.

What steps can reproduce the bug?

  1. Use Codex Desktop on Windows to generate/update the MassNova manual-test package under:

D:\MassNovaManual\quant-large-file-latest

  1. Run:

D:\MassNovaManual\quant-large-file-latest\start-latest-manual-test.cmd

  1. Observe that the command prints:

MassNova manual startup is running in a minimized PowerShell window.
See startup-logs under this directory for details.

  1. Check the latest startup log. For q345:

D:\MassNovaManual\quant-large-file-latest\startup-logs\manual-start-20260618-160240.log

  1. The log stops at:

Starting backend...

  1. The backend never listens on:

127.0.0.1:18120

  1. The machine becomes severely sluggish/stuck from the user's perspective.

openai-codex-copied-backend-freeze-bug-report.md

What is the expected behavior?

Codex should not update a runnable launcher to point to a copied backend executable when that same output root already documents copied backend executables as unsafe.

Expected behavior:

  1. Codex should create hardlinks to the build output instead of copying backend exe files, or launch directly from the build output path.
  2. Codex should validate generated launchers before publishing them as the latest runnable artifact.
  3. If backend startup does not reach 127.0.0.1:18120 within the timeout, Codex should not update start-latest-manual-test.cmd or latest-copy-info.txt to that failing package.
  4. Codex should surface a blocking warning instead of generating a launcher that can make the user's Windows desktop severely sluggish or unusable.

Additional information

Severity: High

This is not only a generated app bug. It is a Codex workflow/product safety issue because Codex generated launchable Windows artifacts that can severely affect desktop usability.

A previous safe package worked when using:

D:\MassNovaManual\quant-large-file-latest\backend-hardlink-safe-20260618-094642\massnova_backend.exe

Later generated packages q344/q345 regressed to copied backend directories:

D:\MassNovaManual\quant-large-file-latest\backend-q344-20260618-154455\massnova_backend.exe
D:\MassNovaManual\quant-large-file-latest\backend-q345-20260618-155807\massnova_backend.exe

The same output root contains:

D:\MassNovaManual\quant-large-file-latest\DO_NOT_RUN_COPIED_BACKEND.txt

which says copied backend processes can hang in loader state on this machine.

View original on GitHub ↗