can't launch codex app after latest update
Open 💬 15 comments Opened Jun 19, 2026 by OldChi
What version of the Codex App are you using (From “About Codex” dialog)?
Codex 26.616.31447
What subscription do you have?
pro 20x
What platform is your computer?
MacOS Darwin 25.5.0 arm64 arm
What issue are you seeing?
Codex failed to start.
Codex app-server initialize handshake timed out.
if I click for updating, it says it's already the latest version (Codex 26.616.31447).
<img width="372" height="365" alt="Image" src="https://github.com/user-attachments/assets/7403bbc8-fcfb-4c51-acf2-ba22845f65cb" />
What steps can reproduce the bug?
launch codex
What is the expected behavior?
_No response_
Additional information
_No response_
15 Comments
I was using codex as usual. After I hit the "update" button, codex can't be launched any more.
can launched now....suddenly
Same problem! I can‘t launch it too!
Codex 26.616.81150
same problem even with todays update
Same problem today again!
same problem here today, after updating codex/chatgpt combined version, cant fix even uninstall and resinstall
@Sere1nz It's a a problem about codex's database, tall codex, codex can fix it self.
@LeiGitHub1024 dude, I cant even launch/open the app to the chat/agent window. How can I even tell it to fix itself? I tried website chat and cli, not fixing it properly.
<img width="352" height="149" alt="Image" src="https://github.com/user-attachments/assets/24abd3ef-c6a7-4c7e-b664-70d163c14698" />
delete cache, reinstall, repair app/reset internet setting wont help at all.
I switched to a different Clash proxy node, and it worked. If you're using proxy software, you can try switching nodes too.
What fixed it for me: my
~/.codex/logs_2.sqlitehad bloated to ~6.7 GB, so theapp-servercouldn't open it before the initialize-handshake timeout. Moving that log DB aside fixed startup instantly.Details — logs only, so auth/config/sessions are untouched and it's reversible:
Check yours first:
ls -lah ~/.codex/logs_2.sqlite*— if it's multiple GB, this is likely the cause. After it starts cleanly,rm ~/.codex/logs_2.sqlite*.bakto reclaim the space. Single machine here, but the unbounded log growth looks like the real bug.@kirill-markin dont work for me, my logs_2.sqlite only has ~75 mb. I also tried deleting .codex folder and reinstall and got the same issue.
@hanyu-zhou I tried, dont work for me.
I find a way to fix it, but it is for temporary.
Windows desktop client: app-server initialize handshake times out over direct stdio
Issue body:
## Environment
OpenAI.Codex_26.707.8168.0_x6426.707.616080.144.1stdio## Problem
The Windows ChatGPT/Codex desktop client consistently failed during startup with:
```text
Codex app-server initialize handshake timed out
The desktop client successfully spawned codex.exe, but the initialization response was not observed before the 30-
second timeout.
Relevant log output:
[StdioConnection] stdio_transport_spawned
[AppServerConnection] Transport start success
[AppServerConnection] Initialize handshake still pending durationMs=30011
[AppServerConnection] initialize_handshake_result
errorMessage="Codex app-server initialize handshake timed out"
outcome=failure
[AppServerConnection] Desktop bootstrap failed to start the main app
## Diagnostics
The following were verified and appeared healthy:
Running the app-server manually with the same configuration and startup arguments worked:
codex.exe
-c features.code_mode_host=true
app-server `
--analytics-default-enabled
When an initialize JSON request was sent manually, the CLI returned a valid response.
I also set CODEX_CLI_PATH to the npm-installed codex.exe. The desktop client used the overridden executable, as
confirmed by its logs, but the direct desktop-to-CLI stdio connection still timed out. This indicates that the bundled
CLI binary itself was not the cause.
## Important finding
I inserted a small local stdio shim between the Electron desktop client and the real npm codex.exe.
The shim:
With the temporary diagnostic shim, I observed:
Final desktop log:
Current reported app-server version: currentVersion=0.144.1 hostId=local
initialize_handshake_result durationMs=397
initializeRequestId=__codex_initialize__
outcome=success
transportKind=stdio
app_server_connection.state_changed
currentState=connecting
initialized=true
next=connected
The client remained operational beyond the previous 30-second timeout and successfully processed configuration,
account, model, thread, and app-server requests.
## Workaround
I installed a non-logging stdio shim at:
%USERPROFILE%\.codex\bin\codex-desktop-stdio-shim.exe
I then set the user-level environment variable:
CODEX_CLI_PATH=%USERPROFILE%\.codex\bin\codex-desktop-stdio-shim.exe
The shim launches the npm-installed Codex CLI and performs line-buffered forwarding with an explicit flush after every
line.
After fully restarting the desktop client, the handshake completed successfully.
## Suspected cause
The evidence points to a Windows-specific stdio transport or buffering issue between the Electron desktop process and
the native Codex app-server process.
It does not appear to be caused by:
The exact lower-level cause is still unknown. Possible areas include:
The fact that a transparent line-buffered shim resolves the issue suggests that the app-server response is valid but is
not reliably delivered or framed when the desktop client connects directly to codex.exe.
## Security note
App-server traffic must not be logged in a production workaround. Shortly after initialization, the desktop client may
request authentication status with token inclusion.
The final shim used for this workaround performs forwarding only and does not persist stdin, stdout, stderr,
authentication data, or JSON-RPC messages.
## Workaround rollback
Once the native desktop stdio issue is fixed, the workaround can be removed with:
[Environment]::SetEnvironmentVariable(
'CODEX_CLI_PATH',
$null,
'User'
)
The desktop client must then be fully restarted.
@kirill-markin worked for me, delete all big log files. THX.