Skip to content

App is almost unresponsive for 5 mins after starting up #16158

Open
Open
App is almost unresponsive for 5 mins after starting up#16158
Labels
appIssues related to the Codex desktop appbugSomething isn't workingmacOSperformance

Description

@Meowzz95
Meowzz95
opened on Mar 29, 2026

What version of the Codex App are you using (From “About Codex” dialog)?

Version 26.325.31654 (1272)

What subscription do you have?

Pro

What platform is your computer?

Darwin 25.4.0 arm64 arm

What issue are you seeing?

The first time I have this issue is at the "plugin" update of the codex app, and currently the version i have is (presumably) the 2nd version after the "plugin" update.

The Codex app is basically unresponsive, click/hover all takes >30s to see the app response in a very very slow way.

CPU shows only ~10% usage from the codex app, so I think this is some slow single thread start up task that is blocking the whole UI.

The only way to use the App is to wait around 5 mins (I think this is to wait the slow task to finish) and the app will become responsive again.

Every quite and start cycle triggers this issue.

What steps can reproduce the bug?

  • close the codex app (cmd + q)
  • reopen codex app
  • observe the app is almost not responsive

What is the expected behavior?

the app should be responsive

Additional information

I'm not sure what I can provide to help you debug this, this has nothing to do with model performance so no thread id is needed.

let me know.

Activity

  1. Meowzz95
    added
    appIssues related to the Codex desktop app
    on Mar 29, 2026
  2. github-actions
    added
    bugSomething isn't working
    on Mar 29, 2026

  3. github-actions commented on Mar 29, 2026

    @github-actions
    github-actionsbot
    on Mar 29, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  4. etraut-openai commented on Mar 29, 2026

    @etraut-openai
    etraut-openai
    on Mar 29, 2026
    Contributor

    After it starts, please use /feedback to upload your logs and paste the thread ID here.

  5. Meowzz95 commented on Mar 29, 2026

    @Meowzz95
    Meowzz95
    on Mar 29, 2026
    Author

    i'm not sure if it is a duplicate as my unresponsive time is certainly more than 30s

  6. Meowzz95 commented on Mar 29, 2026

    @Meowzz95
    Meowzz95
    on Mar 29, 2026
    Author
    Image

    I keep getting this error when submitting feedback from the codex app @etraut-openai what should I do to generate a thread id?

  7. Meowzz95 commented on Mar 29, 2026

    @Meowzz95
    Meowzz95
    on Mar 29, 2026
    Author

    Ok this is the session ID I got from the conversation by right clicking and "copy session ID"

    019d383b-6ed1-73d3-a677-0fb074990837

    Let me know if I need to provide any other stuff @etraut-openai

  8. lucellent commented on Mar 29, 2026

    @lucellent
    lucellent
    on Mar 29, 2026

    Same here on Windows as well.

    Edit: Seems kinda related to my first issue here #13589 (comment)
    I now disabled all kinds of notifications/popups from Codex app and so far no freezing.

  9. Meowzz95 commented on Mar 30, 2026

    @Meowzz95
    Meowzz95
    on Mar 30, 2026
    Author

    is my thread id accessible and provide useful info? any follow up i need to do?

  10. QuickerStudio commented on Mar 30, 2026

    @QuickerStudio
    QuickerStudio
    on Mar 30, 2026

    Please have the official release the new loader and thread manager as soon as possible. Every time it starts, it takes 5 minutes to wait for the initialization to complete, and after loading, the historical chat records of the threads still take 2 minutes to load.
    My friend advised me: You better not close VSCode to avoid wasting time.
    Rust is safe, but its startup time is no less than booting a computer.

  11. Meowzz95 commented on Apr 6, 2026

    @Meowzz95
    Meowzz95
    on Apr 6, 2026
    Author

    this has been a week... anybody looking into this? as codex app is not open sourced, i don't think the community can do anything about this

  12. xingwangyong commented on Apr 6, 2026

    @xingwangyong
    xingwangyong
    on Apr 6, 2026

    Same here. Takes more than 5 minutes to become responsive. Have to switch back to vscode. Windows app does not work at all.

  13. lokafinnsw commented on Apr 28, 2026

    @lokafinnsw
    lokafinnsw
    on Apr 28, 2026

    Subject: Codex App for macOS: local app-server blocks UI RPCs for 80-950s under heavy real-world session history

    Environment:

    • macOS, Codex App for macOS
    • App version observed in logs: 26.422.62136
    • Electron: 41.2.0
    • Codex CLI/app-server reported version: 0.126.0-alpha.8
    • Machine: Apple Silicon M5 Max, 128 GB RAM
    • Network to api.openai.com appears healthy: unauthenticated /v1/models checks returned in ~0.23-0.30s total

    Issue:
    Codex App becomes extremely slow on startup and during normal navigation:

    • long hang on startup/loading screen
    • very slow switching between sessions
    • model list takes a long time to appear
    • submitting/steering a turn can time out

    This does not look like an OpenAI API/network latency issue. The local Electron UI -> Codex app-server RPC path is returning very slowly.

    Evidence from Codex App logs:
    Current log file:
    ~/Library/Logs/com.openai.codex/2026/04/28/codex-desktop-4d8304d2-d28d-476b-959e-fb4cc961f49c-72130-t0-i1-141200-0.log

    Startup:

    • app-server transport started at 14:12:03
    • initialize handshake succeeded in 4048 ms
    • renderer routes mounted only after 34212 ms
    • getAuthStatus timed out after 30000 ms

    Representative slow RPCs:

    • config/read: 956583 ms
    • experimentalFeature/enablement/set: 926487 ms
    • thread/resume: 354896 ms
    • account/read: 354861 ms
    • plugin/list: 354594 ms
    • thread/list: 151375 ms
    • account/read: 150006 ms
    • config/read: 146715 ms
    • experimentalFeature/list: 98698 ms
    • model/list: 14253 ms
    • app/list: 15234 ms
    • turn/steer timed out after 30000 ms, later routed after 91719 ms

    Process evidence:

    • /Applications/Codex.app/Contents/Resources/codex app-server --analytics-default-enabled
    • app-server CPU observed between ~74% and ~157%
    • app-server RSS observed between ~3.3 GB and ~6.6 GB
    • Codex renderer CPU observed up to ~114%

    Local state/workload:

    • ~/.codex is ~41 GB
    • ~/.codex/sessions is ~39 GB
    • 1179 rollout JSONL files
    • 75 session JSONL files >100 MB
    • 21 session JSONL files >500 MB
    • 7 session JSONL files >1 GB
    • logs_2.sqlite around ~235-258 MB
    • state_5.sqlite has 951 threads
    • Some thread titles / first_user_message fields are very large, up to ~122 KB

    logs_2.sqlite showed active high-volume logging around responses_websocket / tokio-tungstenite / SSE while UI RPCs were delayed.

    Hypothesis:
    This appears to be head-of-line blocking or task starvation inside the local Codex app-server. Heavy live session processing, JSONL/session writes, SQLite/log writes, plugin/config/account/thread/model UI RPCs appear to share a bottleneck. Lightweight UI operations like thread/list, config/read, account/read, and model/list should not wait tens or hundreds of seconds behind live session processing.

    Expected behavior:

    • thread/list, config/read, account/read, model/list should remain responsive even when a long active session is streaming or writing rollout data.
    • model/list should not take 14s locally when network to api.openai.com is ~0.25s.
    • UI navigation and startup should degrade gracefully with large session history.

    Request:
    Please investigate app-server scheduling/locking around:

    • thread/list and session index loading
    • model/list path
    • config/account/plugin list RPC handling
    • SQLite access/log writing contention
    • large rollout JSONL files
    • high-volume TRACE/WebSocket/SSE logging
    • whether active session processing can block unrelated UI RPCs

    I can provide logs and sanitized command output if helpful.

  14. ambrosino-oai
    added
    macOS
    on Apr 28, 2026
  15. etraut-openai
    added
    performance
    on May 3, 2026

  16. basilkorompilias commented on May 3, 2026

    @basilkorompilias
    basilkorompilias
    on May 3, 2026

    Windows 11, same issue. I click the icon to start, I wait for 5 sometimes 15m until the window just appears. Now after a few sessions it starts and completely crashes. I uninstalled, reinstalled but that fixed nothing. I am a new user - I use it around a week or two. Never had issues with Cursor or VS Code. I have 32GB Ram.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbugSomething isn't workingmacOSperformance

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions