Codex becomes unresponsive on startup if the `~/.ssh/config` is large

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

• #16158
• #15963

Powered by Codex Action

Amazing, how did you find out it is related to ssh config? I can confirm that it is the same case here as well.
800+ lines of ssh config -> almost 5 mins of unresponsiveness
100+ lines -> less than 1 min

@Meowzz95 I used codex cli too debug it 😄

In an old version of codex app, the app wouldn't even load, so I had to investigate it.

<details><summary>Here's the debugging from codex:</summary>
<p>

• I have confirmation. I’m verifying whether the Codex Helper*.ips crash reports are tied to com.openai.codex; then I’ll remove only the confirmed Codex data paths and report what was
deleted.

• I verified the crash reports are from /Applications/Codex.app and com.openai.codex.helper. I’m deleting only the com.openai.codex data and those Codex helper crash reports now, then I’ll
verify what remains.

• Deleted the local data for Codex.app and verified the target paths are gone, including the Codex Helper (Renderer) crash reports. I did not remove /Applications/Codex.app itself, and I
did not touch CodexBar.

If Codex was still running while this happened, it may recreate some files on launch. The next sensible step is to quit it fully and try opening it again; if it still fails, I can remove
the app bundle and help you reinstall cleanly.

› so it loads but says Something went wrong…

• I’m inspecting the new Codex logs and recent app data that were recreated after launch to see what is behind the generic error screen.

• The app recreated a fresh profile and wrote one new desktop log. I’m reading that log for the first failing request or renderer error rather than guessing.

• The main process log points to a renderer-side failure: the window starts, then the app bundle load is aborted and the remote-connections probe is failing with spawn EBADF. I’m checking
the fresh crash report and any renderer logs next.

• I have the symptom narrowed to the renderer falling back to the built-in error page, not an auth prompt. I’m opening the fresh renderer crash report to see whether this is a hard crash
or an internal navigation failure.

• The crash report confirms the renderer is aborting itself with SIGABRT, not just failing a network call. I’m digging one level deeper into the renderer telemetry for the actual JS/
runtime error that triggered the abort.

• The telemetry isn’t showing a clean JS stack, only the fallback error page after the renderer aborts. I’m checking whether the packaged app contains inspectable source paths for the
failing startup code so I can see what it aborts on.

• The packaged logs stop at the fallback page, so I’m starting the app binary directly from the terminal to capture any stderr/stdout from the renderer crash path.

• I’m checking the app bundle’s declared macOS requirement next. If the current build expects a newer macOS than 15.1, that would fit a clean reinstall not helping.

• The only concrete startup failure besides the renderer abort is the remote-SSH discovery path. I’m checking whether your ~/.ssh/config setup is unusual enough to trip the app on startup
without reading sensitive contents unnecessarily.

• ~/.ssh/config is present and very large at about 1.7 MB, which makes the remote-discovery path more suspicious. I’m searching the packaged app strings for any startup flags or code paths
tied to remote connections before I suggest a workaround that touches your SSH config.

• I’m waiting on the string scan. If the app embeds a startup switch to skip remote discovery or a known fallback mode, that’s the cleanest next step.

• I’m symbolizing the tiny native crash offsets in Codex Helper (Renderer) now. If those resolve to Chromium crash helpers only, this is likely an upstream app bug; if they resolve to a
specific subsystem, we can target a workaround.

• The failure pattern is consistent with a renderer startup crash. I’m going to test a standard Electron workaround by opening Codex.app once with --disable-gpu; that requires permission
because it launches a GUI app outside the sandbox.

• I launched a fresh instance with --disable-gpu. I’m checking whether it still produced the same renderer crash or made it past the fallback error page.

• The launch didn’t create a new crash report or a new desktop log immediately, which is inconclusive from the shell side. I’m checking file timestamps once more before I ask you what the
window did on screen.

• The logs still point most strongly at startup work around remote SSH discovery, and your SSH config is unusually large. I’m getting non-sensitive counts from that file so I can judge
whether it’s worth testing with a temporary empty config.

• Searched site:help.openai.com Codex desktop app remote connections SSH config crash

────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

• This is no longer a stale-cache problem. The current Codex.app build is crashing its renderer on startup.

What I found:

• The fresh log at Library/Logs/com.openai.codex/2026/03/27/codex-desktop-401fa893-091a-42e4-9d40-1a80aa3ca5c6-3235-t0-i1-111711-0.log shows startup reaching remote SSH discovery, then

failing with spawn EBADF, then falling back to the built-in Something went wrong… page.

• The crash report at Library/Logs/DiagnosticReports/Codex%20Helper%20(Renderer)-2026-03-27-121719.ips confirms Codex Helper (Renderer) aborted with SIGABRT.
• Your .ssh/config is very large: 43,204 lines with 5,399 Host entries. That is the strongest local signal I have for the startup crash path.

The next clean test is to temporarily get Codex away from that SSH config. If you want, I can:

1. Move .ssh/config to a timestamped backup.
2. Create a minimal empty replacement.
3. Have you relaunch Codex.
4. Restore the original file afterward if needed.

I will not inspect the contents. If you want me to do that, reply:

</p>
</details>

So now in a newer version, it now loads, but I was guessing it could be an issue

@kilianyp amazing. yet openai can't fix this or doesn't care to fix this for more than a week. i think they're using all their resource to see how to secretly reduce usage limit on their paying customer now. what a bad move

I had same issue. So codex CLI figured it out and patched my local install.

The expanded SSH config is the real scale problem here: your 20-line ~/.ssh/config pulls in 18 files with about 2,417 Host entries. That explains why desktop remote discovery can hammer ssh process creation and hit EAGAIN even though the top-level file is small.

I’ve traced the exact bug in the shipped desktop code. On startup it expands all SSH aliases, then does Promise.all(aliases.map(alias => ssh -G -F ~/.ssh/config alias)), so with your expanded config that means about 2,417 concurrent ssh -G child-process launches and macOS eventually returns EAGAIN.

So I asked the codex CLI to patch my local install, and it works. Maybe add a toggle to not scan ssh configure on startup?

Following, having the same issue. I need those aliases in my config file so i have to create a backup so codex doesn't take 5-10minutes just to boot up. They need to fix this ASAP

Not seeing the issue in latest version of codex app.(26.406.31014).

Just as an additional code point, my ~/.ssh/config has 181 lines (3318 bytes) and I don't see slowdown during startup on Ubuntu Linux. Maybe the actual limit is exceeding 4 KB page size?

I also don't see it anymore