Windows/WSL: PowerShell system32 prompt appears during active Codex CLI session

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #23333

Powered by Codex Action

In fact codex is running properly but without any manual intervention it
switches to system32 and close the codex session. It's just beginning
today. Perhaps after the update ?

Codex has written me a "stable" launcher : [launcher stable] Codex sans
alt-screen, sans terminal reflow experimental, sans plugins. It seems
better but it crashed at one time.

Best regards,

Jean-Christophe Niquet

Le mar. 19 mai 2026 à 17:51, Keesan @.***> a écrit :

Keesan12 left a comment (openai/codex#23485) <https://github.com/openai/codex/issues/23485#issuecomment-4489536531> This reads like terminal-focus admission is leaking between the active Codex session and the parent shell. The important distinction in the report is that the working directory is initially correct and only later a stale PowerShell surface starts qualifying as the active input target. That suggests the bug is less about cwd setup and more about lifecycle ownership: which terminal currently owns keystrokes, which background terminal is still alive, and what event is allowed to reclaim focus. I would want the app to leave an explicit focus/terminal receipt whenever it switches or reattaches, because once stray input is admitted into system32 the failure is no longer cosmetic. That is very close to the runtime-boundary seam we care about in MartinLoop. If useful, the repo is public and I’d love blunt feedback; if it helps, a star genuinely helps keep the OSS work moving. — Reply to this email directly, view it on GitHub <https://github.com/openai/codex/issues/23485#issuecomment-4489536531>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BFJVLPLE2JQFPIQVEYMKADD43R7GJAVCNFSM6AAAAACZENANKGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DIOBZGUZTMNJTGE> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you authored the thread.Message ID: @.***>

--
Cordialement,

Jean-Christophe NIQUET
07 68 57 27 21

I m a new bee don't know how starring an answer ?

Thanks, that extra detail helps.

If it starts in the right cwd and only later snaps back to system32 and kills the session, I would instrument the reattach/focus-transfer path rather than the launcher path. A tiny receipt every time ownership changes would probably make this much easier to isolate:

• previous terminal/session id
• new terminal/session id
• cwd at handoff
• why the handoff happened (reattach, helper-exit, focus-restore, etc.)

That would separate "helper window exists" from "helper reclaimed input", which sound similar from the outside but are very different bugs.

And on the star question: if you ever want to star a repo on GitHub, the Star button is in the top-right of the repo page. No pressure though; the repro details are the genuinely useful part here.

Dear,
Last night Codex had a brutal crisis with the supposed "stable" launcher,
repeatedly windows 32 killing the session one minute after beginning to
work in a codex session.

I will try to log the problem and send you.

Best regards,

Jean-Christophe

Le mar. 19 mai 2026 à 18:33, Keesan @.***> a écrit :

Keesan12 left a comment (openai/codex#23485) <https://github.com/openai/codex/issues/23485#issuecomment-4489890196> Thanks, that extra detail helps. If it starts in the right cwd and only later snaps back to system32 and kills the session, I would instrument the reattach/focus-transfer path rather than the launcher path. A tiny receipt every time ownership changes would probably make this much easier to isolate: - previous terminal/session id - new terminal/session id - cwd at handoff - why the handoff happened (reattach, helper-exit, focus-restore, etc.) That would separate "helper window exists" from "helper reclaimed input", which sound similar from the outside but are very different bugs. And on the star question: if you ever want to star a repo on GitHub, the Star button is in the top-right of the repo page. No pressure though; the repro details are the genuinely useful part here. — Reply to this email directly, view it on GitHub <https://github.com/openai/codex/issues/23485#issuecomment-4489890196>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BFJVLPN5OFTFQSPY6TY5YY343SEHPAVCNFSM6AAAAACZENANKGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DIOBZHA4TAMJZGY> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you authored the thread.Message ID: @.***>

--
Cordialement,

Jean-Christophe NIQUET
07 68 57 27 21

Hey, I’ve been hitting this too from time to time. For me it mostly happened when an agent tried to SSH into a server and SSH fell back to a password prompt.

I finally got a deterministic repro on Windows:

1. Have Codex run this through exec_command with tty omitted:

tools.exec_command({
  cmd: "ssh -o PubkeyAuthentication=no -o PreferredAuthentications=password -o NumberOfPasswordPrompts=1 ubuntu-server true",
  yield_time_ms: 10000,
  max_output_tokens: 1000
})

1. Don’t enter a password.
2. After around 10–15 seconds, the SSH prompt gets written directly over the Codex input line and starts consuming keyboard input. Ctrl+C gets control back.

I can reproduce it both inside a terminal multiplexer like herdr and directly in Windows Terminal, so the multiplexer doesn’t seem involved. The same SSH prompt works correctly when the command uses tty: true: it stays inside the background terminal and Codex keeps its input.

It looks like Windows non-TTY children still inherit Codex’s parent console. The non-TTY pipe path redirects stdio, but only detaches from the controlling terminal on Unix. That lets Windows OpenSSH use the parent CONIN$ / CONOUT$ directly and bypass the tool capture.

The likely fix seems to be starting Windows non-TTY children without the parent console (CREATE_NO_WINDOW / the existing ConsoleMode::NoWindow path), while keeping the current ConPTY behavior for tty: true.

Gonna try this in my fork and edit the conclusion here once I know whether it actually fixes it.

Update

I ended up (hopefully) fixing the core issue in PR #85 by detaching Windows non-TTY child processes from Codex’s console.

While testing that, I figured it also made sense to guard the console-input recovery path so an unexpected console change can’t leave Codex stuck waiting forever. That follow-up is in PR #86.

Retested the merged release build with the exact command above: no prompt leaked into the composer and keyboard input remained responsive. I also tested with tty: true; the password prompt correctly stayed inside the background terminal.

Looks fixed on my end. I’ll keep running the fork and update this if it happens again.

Happy to provide more info/diagnosis for someone fixing this for real.