New ChatGPT/Codex Windows app opens multiple SSH sessions, causing repeated YubiKey PIN and touch prompts

I’m testing the newly released ChatGPT Windows app with the built-in Codex SSH remote connection feature.

The SSH connection works, but every time the app reconnects to my Linux development server, I have to enter my YubiKey PIN and touch the key repeatedly before the connection finishes.

My SSH setup intentionally requires a FIDO2 hardware key:

  • Windows client
  • Native Windows OpenSSH
  • YubiKey using an ED25519-SK SSH key
  • PIN verification and physical touch required
  • Remote server running Ubuntu 26.04
  • Remote Codex CLI version: 0.144.4

A normal manual connection behaves correctly:

ssh devlinux

That results in one PIN prompt, one YubiKey touch, and then a successful login.

However, I monitored the ssh.exe processes created by the ChatGPT/Codex app during a reconnect. The app opened four separate SSH processes, all from the same parent application process:

1. Check whether Codex exists:
command -v codex

  1. Check the Codex version:
    codex --version

  2. Start the remote app server:
    codex app-server --listen unix://

  3. Open the persistent proxy:
    codex app-server proxy

Each command is launched through a separate invocation similar to:

ssh -v -o BatchMode=yes -o ServerAliveInterval=15 -o ServerAliveCountMax=12 devlinux …

Because each is a completely separate SSH authentication, the YubiKey correctly requires another PIN verification and touch for every connection.

The timestamps from one reconnect were:

15:52:03 — Check for Codex
15:52:27 — Check Codex version
15:52:35 — Start app server
15:52:42 — Open app-server proxy

The commands all had the same parent PID, so they appear to be part of the app’s normal connection workflow rather than unrelated SSH activity. The complete process log confirms the four independent stages.

This makes reconnecting fairly painful for anyone using hardware-backed SSH authentication. On Windows, standard OpenSSH connection multiplexing is also not readily available as a workaround.

Could the app reuse one authenticated SSH transport for these setup operations, or combine the prerequisite checks and app-server startup into a single SSH session?

At minimum, it would be helpful if the app could avoid performing the Codex existence and version checks again during every reconnect when the remote configuration has not changed.

This topic was automatically closed after 24 hours. New replies are no longer allowed.