TUI/CLI performance regression from 116 to 117

Can you provide more details about what you're seeing? What part of the launch is slow for you?

On macOS and Linux is also extremely slow

https://github.com/user-attachments/assets/9e87ba9a-d6e3-446a-a679-1547acddb055

And also some discussion: https://www.reddit.com/r/codex/comments/1s66vye/is_it_me_or_codex_cli_start_to_get_slower/

Can you provide more details about what you're seeing? What part of the launch is slow for you?

Answering for Linux here. It’s the same as you can see in the beginning of @zeyugao video

I start a lot of codex sessions for small tasks, so this is very noticeable. We are talking about the time it takes from starting codex cli until you can start to (visibly) type.

Up until 0.116 I see the UI instantly and can instantly start to type my prompt

In 0.117 and 0.118 I need to wait 2 seconds (on a top-end developer machine) until I see the UI and can start to (visibly) type.

And because we also need to wait for the app's bootstrap before typing anything, I may need to wait 5 seconds or even longer to begin a conversation.

<img width="1902" height="113" alt="Image" src="https://github.com/user-attachments/assets/3255d614-626c-48ca-bbbc-a6a8f866788c" />

I investigated this locally and was able to narrow the 0.116 -> 0.117+ regression down to the app-server-backed TUI startup path.

Findings:

• 0.116.0 is fast, 0.117.0+ is noticeably slower before the first prompt becomes interactive
• the regression is not primarily terminal-related in my case
• the main avoidable pre-paint costs are:
• extra app-server/bootstrap work before first paint
• more bootstrap than needed just to determine login status
• synchronous startup account/rateLimits/read

I put together a candidate fix here:
https://github.com/openai/codex/compare/main...changjonathanc:fix/tui-startup-latency?expand=1

What that branch changes:

• reuse the startup app-server session when onboarding is skipped instead of starting a second one
• use account/read directly for login-status detection instead of full bootstrap
• move startup account/rateLimits/read off the critical path so it loads asynchronously after app construction

Validation on the branch:

• just fmt
• cargo test -p codex-tui
• cargo build -p codex-cli

@changjonathanc I also tracked the slowdown to rateLimits. It looks the rate-limits RCP takes 600ms to respond (from Europe) and it's called twice(!) during startup. It's part of bootstrap() which is also called twice: Once just to get a login status 💦 Possibly related to this commit: https://github.com/openai/codex/commit/fc97092f75

I found that running codex inside Jetbrains IDEs adds another 2s to startup time. It's because the IDEs do not respond to OSC 11/11 queries and crossterm is waiting for 2s timeout. This fixes it: https://github.com/JetBrains/intellij-community/pull/3477

I was able to work around this previously by disabling a Codex feature (codex features disable tui_app_server). This feature is no longer disabled, and I cannot disable it because its flag has been removed:

# codex --version
codex-cli 0.118.0

# codex features list | grep tui
tui_app_server                   removed            true

Downgrading eliminated the issue for me:

# codex --version
codex-cli 0.116.0

# codex features list | grep tui
tui_app_server                   experimental       false

This will be addressed in the next release. See this PR for details.

@etraut-openai @fcoury-oai this is not really fully address. 0.116 is still much much faster to startup than 0.119 (alpha.33).

0.119 is faster than 0.117 but still about 1s to start whereas before it was instant

@howardjohn, thanks for the report. Reopening for additional investigation.

@etraut-openai I updated my patch to remove what's already covered by your merged code. this PR now simply adds app-server reuse across onboarding/startup. it should provide additional speedup and solve the issue.

https://github.com/openai/codex/compare/main...changjonathanc:fix/tui-startup-latency?expand=1
(vibe coded with codex)

I had the exact same issue using codex-cli 0.125.0. Resolved by simply re-installing it (brew reinstall codex)

We are seeing the same regression, and I want to underscore the severity from a real workflow perspective.

Codex CLI startup responsiveness was one of the main reasons we preferred and recommended Codex over Claude Code. The near-instant launch made it viable to start many short-lived sessions throughout the day. We have recruited people into the OpenAI/Codex ecosystem specifically because of that speed. The current 1-2s delay before the TUI is visibly usable changes that product feel in a very material way.

Local data from one affected Linux workstation:

• Codex: codex-cli 0.130.0
• Binary: /usr/bin/codex
• OS: Linux 6.12.69-2-cachyos-lts-lto x86_64
• tui_app_server: removed true, so the old workaround is no longer available
• codex --version: 0.237s with normal CODEX_HOME
• codex --version: 0.579s with clean CODEX_HOME
• codex mcp list: 1.812s with normal config
• codex mcp list: 1.276s with clean CODEX_HOME and no MCP servers
• Configured MCP servers in normal config: 2 enabled stdio servers
• ~/.codex/sessions: 3120 JSONL files, 18G total
• ~/.codex/logs_2.sqlite: 862M
• ~/.codex/state_5.sqlite: 14M

There is definitely local history pressure on this machine, so that may overlap with the newer session/app-server performance issues. But that is important context rather than a reason to discount this regression: opening a fresh TUI should not need to hydrate, deeply scan, deserialize, index, summarize, or otherwise block on local conversation history before the composer is usable.

The key signal for this issue is that even a clean CODEX_HOME has a ~1s+ floor for startup-adjacent Codex commands, and the observed interactive TUI launch delay matches the reports here: previously instant, now roughly 1-2 seconds before typing is visibly usable.

This should be treated as a first-paint / first-keystroke regression. Opening a fresh TUI should not depend on local conversation history, MCP inventory completion, rate-limit reads, full app-server bootstrap, or any other nonessential background work. Those can load after the composer is usable.

For users who launch Codex constantly for small tasks, this is not cosmetic. Startup speed was core product value.

I dug into this as a first-paint / first-keystroke regression.

TL;DR

The remaining slowdown looks like app-server/bootstrap work still being awaited before the TUI is handed to App::run. My proposed fix is to keep the pre-App path limited to startup hook-review state, then let app-server bootstrap/default-thread work happen after the TUI exists.

Problem

The symptom described here is specifically that codex starts but the TUI is not visibly usable for ~1-2s, whereas 0.116 showed the composer essentially immediately. That matches the later reports in this thread: the painful part is the delay before a user can start typing, not only total process startup time.

Building on the earlier startup-latency work in #17039, my read is that there is still avoidable work on the pre-App critical path. Around codex-rs/tui/src/lib.rs, startup prefetch happens before the TUI is handed to App::run. If that path awaits app-server bootstrap/default-thread/account/model setup, the UI cannot draw until those async calls complete.

Mental model

I think the startup work should be split into two buckets:

1. Pre-App: only what is required to decide whether startup hook review must be shown.
2. Post-App: app-server bootstrap/default-thread/model/account work that can complete after the TUI exists.

That keeps startup behavior correct while moving nonessential latency off the first-paint path.

Preview branch

I have a focused branch with this shape of fix:

Branch:
https://github.com/ChronoAIProject/codex/tree/codex-saga/fix-codex-triage_dup_openai_codex_16335

Compare against upstream main:
https://github.com/openai/codex/compare/main...ChronoAIProject:codex-saga/fix-codex-triage_dup_openai_codex_16335

Validation

On that branch:

• just fmt
• just test -p codex-tui
• Result: 2954 tests run: 2954 passed, 4 skipped

Non-goals / tradeoffs

• This does not try to solve all startup latency sources.
• It does not change model/account semantics.
• It specifically targets work that blocks first paint before the composer is visible.
• If maintainers prefer a different startup boundary, I can adjust the branch before opening a PR.

I can open this as a PR if maintainers want to evaluate this direction.

This analysis was prepared with AI assistance.

<!-- fkst:codex-saga:engage:codex-triage:dup:openai/codex#16335 -->