TUI/CLI performance regression from 116 to 117

What version of Codex CLI is running?

0.117.0

What subscription do you have?

Business

Which model were you using?

5.4

What platform is your computer?

Windows 11

What terminal emulator and version are you using (if applicable)?

Windows Terminal

What issue are you seeing?

Launching codex takes multiple seconds, where it used to be instantaneous. The CLI speed is virtually the only reason to use codex over the other JS-based TUIs.

What steps can reproduce the bug?

Update to 0.117.0 and launch the cli.

What is the expected behavior?

No response

Additional information

No response

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

Screen.Recording.2026-04-01.at.15.32.33.mov

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

@zeyugao

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.

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

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.

[1 of 2] Optimize TUI startup terminal probes (#23175)

[2 of 2] Start fresh TUI thread in background (#23176)

[1 of 2] Optimize TUI startup terminal probes (openai#23175)

[2 of 2] Start fresh TUI thread in background (openai#23176)

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:

Pre-App: only what is required to decide whether startup hook review must be shown.
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:
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.

Navigation Menu

Repository navigation

TUI/CLI performance regression from 116 to 117 #16335

What version of Codex CLI is running?

What subscription do you have?

Which model were you using?

What platform is your computer?

What terminal emulator and version are you using (if applicable)?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

10 remaining items

TL;DR

Problem

Mental model

Preview branch

Validation

Non-goals / tradeoffs

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

TUI/CLI performance regression from 116 to 117 #16335

Description

What version of Codex CLI is running?

What subscription do you have?

Which model were you using?

What platform is your computer?

What terminal emulator and version are you using (if applicable)?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Activity

etraut-openai commented on Mar 31, 2026

zeyugao commented on Apr 1, 2026

audaki commented on Apr 1, 2026

winoros commented on Apr 2, 2026

changjonathanc commented on Apr 2, 2026

10 remaining items

semanser commented on Apr 29, 2026

oxysoft commented on May 14, 2026

ctkm-aelf commented on Jul 1, 2026

TL;DR

Problem

Mental model

Preview branch

Validation

Non-goals / tradeoffs

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions