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_

View original on GitHub ↗

15 Comments

OldChi · 1 month ago

I was using codex as usual. After I hit the "update" button, codex can't be launched any more.

OldChi · 1 month ago

can launched now....suddenly

LeiGitHub1024 · 26 days ago

Same problem! I can‘t launch it too!
Codex 26.616.81150

lord007tn · 25 days ago

same problem even with todays update

LeiGitHub1024 · 24 days ago

Same problem today again!

Sere1nz · 11 days ago

same problem here today, after updating codex/chatgpt combined version, cant fix even uninstall and resinstall

LeiGitHub1024 · 10 days ago
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.

Sere1nz · 9 days ago
> 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.

Sere1nz · 9 days ago

<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.

hanyu-zhou · 8 days ago
<img alt="Image" width="352" height="149" src="https://private-user-images.githubusercontent.com/32921181/620462008-24abd3ef-c6a7-4c7e-b664-70d163c14698.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3ODM4NDI3ODQsIm5iZiI6MTc4Mzg0MjQ4NCwicGF0aCI6Ii8zMjkyMTE4MS82MjA0NjIwMDgtMjRhYmQzZWYtYzZhNy00YzdlLWI2NjQtNzBkMTYzYzE0Njk4LnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNjA3MTIlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjYwNzEyVDA3NDgwNFomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPWU0NjYzYTBmZTM0MzgyMWI1NWI3MDdmM2IwZjQ5YmIxNzg2NmFkYTExMTkzNmRhOTU4YzZhMDgzMWE3OTUyYzMmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JnJlc3BvbnNlLWNvbnRlbnQtdHlwZT1pbWFnZSUyRnBuZyJ9.JZgXskmYrwALQAi0cYTE4KucwmdaIiEiI-_lwxmAxmQ"> 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.

kirill-markin · 8 days ago

What fixed it for me: my ~/.codex/logs_2.sqlite had bloated to ~6.7 GB, so the app-server couldn'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:

# 1. quit the app
osascript -e 'tell application "ChatGPT" to quit'
pkill -f "/Applications/ChatGPT.app"

# 2. move the oversized log DB aside
cd ~/.codex
mv logs_2.sqlite logs_2.sqlite.bak
mv logs_2.sqlite-wal logs_2.sqlite-wal.bak 2>/dev/null
mv logs_2.sqlite-shm logs_2.sqlite-shm.bak 2>/dev/null

# 3. relaunch — a fresh, small logs_2.sqlite is recreated
open -a ChatGPT

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*.bak to reclaim the space. Single machine here, but the unbounded log growth looks like the real bug.

Sere1nz · 8 days ago
What fixed it for me: my ~/.codex/logs_2.sqlite had bloated to ~6.7 GB, so the app-server couldn'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: # 1. quit the app osascript -e 'tell application "ChatGPT" to quit' pkill -f "/Applications/ChatGPT.app" # 2. move the oversized log DB aside cd ~/.codex mv logs_2.sqlite logs_2.sqlite.bak mv logs_2.sqlite-wal logs_2.sqlite-wal.bak 2>/dev/null mv logs_2.sqlite-shm logs_2.sqlite-shm.bak 2>/dev/null # 3. relaunch — a fresh, small logs_2.sqlite is recreated open -a ChatGPT 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*.bak to 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.

Sere1nz · 8 days ago
> <img alt="Image" width="352" height="149" src="https://private-user-images.githubusercontent.com/32921181/620462008-24abd3ef-c6a7-4c7e-b664-70d163c14698.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3ODM4NDI3ODQsIm5iZiI6MTc4Mzg0MjQ4NCwicGF0aCI6Ii8zMjkyMTE4MS82MjA0NjIwMDgtMjRhYmQzZWYtYzZhNy00YzdlLWI2NjQtNzBkMTYzYzE0Njk4LnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNjA3MTIlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjYwNzEyVDA3NDgwNFomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPWU0NjYzYTBmZTM0MzgyMWI1NWI3MDdmM2IwZjQ5YmIxNzg2NmFkYTExMTkzNmRhOTU4YzZhMDgzMWE3OTUyYzMmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JnJlc3BvbnNlLWNvbnRlbnQtdHlwZT1pbWFnZSUyRnBuZyJ9.JZgXskmYrwALQAi0cYTE4KucwmdaIiEiI-_lwxmAxmQ"> 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.

@hanyu-zhou I tried, dont work for me.

Sere1nz · 7 days ago

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

  • OS: Windows 11 Pro, build 26200, x64
  • Installed desktop package: OpenAI.Codex_26.707.8168.0_x64
  • Desktop-reported version: 26.707.61608
  • npm Codex CLI: 0.144.1
  • Transport: local stdio

## 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:

  • Codex configuration parsed successfully.
  • ChatGPT authentication was valid.
  • HTTP provider endpoints were reachable.
  • The Responses WebSocket handshake succeeded.
  • Codex SQLite databases passed integrity checks.
  • No MCP servers were configured.
  • The npm CLI installation passed codex doctor.

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:

  1. Receives the arguments passed by the desktop client.
  2. Starts the real codex.exe.
  3. Redirects stdin, stdout, and stderr.
  4. Forwards each stream line by line and flushes it immediately.
  5. Does not modify the JSON messages.

With the temporary diagnostic shim, I observed:

  • The desktop client sent a valid initialize request.
  • The real app-server returned a valid response in approximately 120 ms.
  • The response was forwarded unchanged.
  • The desktop client then completed its handshake successfully.

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:

  • Network connectivity
  • Authentication
  • User configuration
  • SQLite corruption
  • The bundled codex.exe
  • The npm codex.exe
  • The app-server initialization request itself

The exact lower-level cause is still unknown. Possible areas include:

  • Electron/Node child_process pipe handling on Windows
  • Native Windows anonymous pipe behavior
  • Output buffering or flushing
  • NDJSON line framing
  • A timing-related regression in the desktop client's stdio transport

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.

ruoqianfengshao · 19 hours ago

@kirill-markin worked for me, delete all big log files. THX.