›_ Codex Issues
Codex Issues / #19483

Regression: codex resume picker slowed from 2-3s to 8-60s after updating to 0.124.0

Resolved 💬 5 comments Opened Apr 25, 2026 by chalgoon9 Closed Apr 27, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of Codex CLI is running?

0.124.0

What subscription do you have?

[Please fill in: Plus / Pro / Team / Enterprise]

Which model were you using?

gpt-5.5

What platform is your computer?

Linux lia-server 6.8.0-110-generic #110-Ubuntu SMP PREEMPT_DYNAMIC Thu Mar 19 15:09:20 UTC 2026 x86_64 x86_64 x86_64 GNU/Linux

Node.js: v22.22.0
npm: 10.9.4
Install path: /home/lia/.npm-global/bin/codex

What terminal emulator and version are you using?

[Please fill in]

What issue are you seeing?

After updating Codex CLI to the recent version 0.124.0, codex resume became excessively slow when opening the resume picker.

This is a regression after the recent CLI update, not simply a case of having a large local history. Before the update, the same machine and accumulated session history loaded the resume picker in about 2-3 seconds. After updating to 0.124.0, the same workflow became much slower.

The slowdown appears to scale with the number and total size of local session JSONL files after the update, but the important point is that this history was previously usable. I want to keep my session history, so deleting old sessions is not an acceptable long-term workaround.

Current local state after manually archiving old session files outside the active scan path:

Codex CLI: 0.124.0
Model: gpt-5.5
Active session JSONL files under ~/.codex/sessions: 27
Active session directory size: 260M
Archived session JSONL files moved outside active scan path: 821
Archived session size: 3.1G
State DB thread rows: 833
Visible rows: 36
Archived rows: 797

Even after reducing the active session set to only 27 JSONL files, codex resume still takes around 8 seconds for the picker list to become visible.

Measured after reinstalling the same CLI version:

run 1: 8.236s
run 2: 7.927s
run 3: 7.982s

Before physical archiving, with the full session history in the active scan path, the full load after the update was much worse:

Average first list: about 10.22s
Average full load: about 62.83s

Different active retention sizes showed that the slowdown scales with session history size:

30-day active keep:
- 82 files
- 2.1G
- full load: about 40-46s

14-day active keep:
- 49 files
- 449M
- full load: about 10-18s
- average: about 12.75s

7-day active keep:
- 25-27 files
- about 253-260M
- full load/list visible: about 6-8s

Reinstalling @openai/codex@0.124.0 did not improve the behavior. npm uninstall/install completed successfully and the package files were refreshed, but resume loading remained slow.

What steps can reproduce the bug?

  1. Use Codex CLI 0.124.0.
  2. Accumulate many local Codex sessions under ~/.codex/sessions, including large JSONL files.
  3. Run:
codex resume
  1. Observe that the resume picker remains on Loading sessions... for a long time.
  2. Reduce the active session set and observe that loading time improves roughly with fewer/smaller JSONL files, but remains slow even with a relatively small active set.

What is the expected behavior?

codex resume should open the resume picker quickly even when the user has a large local session history.

The picker should not require scanning or parsing large amounts of JSONL before becoming usable. It should preferably use the state DB/index first, render quickly, and load heavier history lazily only when needed.

Keeping long-term session history should not make the native resume picker progressively slower.

Additional information

I want to preserve session history and continue using the native codex resume command. Manual archiving of old JSONL files improves load time, but this is only a workaround and requires external session management.

The regression became noticeable only after updating to the recent Codex CLI version. Before the update, the resume picker was typically usable in about 2-3 seconds with the accumulated local history. I am avoiding CLI rollback because this version is also tied to GPT-5.5 availability in Codex, and I want to keep using gpt-5.5.

There may be an architectural issue in the resume picker path where it still scans/parses session JSONL files instead of relying primarily on the state DB metadata.

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 4 months ago

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

  • #18839
  • #19278

Powered by Codex Action

etraut-openai contributor · 4 months ago

Thanks for the bug report. Can you confirm that this problem showed up first in 0.124.0? If you downgrade to 0.123.0 on your system, do you see a different behavior? This will help us track down the cause more quickly. Thanks!

chalgoon9 · 4 months ago

I ran the requested downgrade comparison, and the result strongly indicates that this is a CLI regression introduced between 0.123.0 and 0.124.0.

This does not look like a general "large session history" issue. Under the same cwd and the same current session state, 0.123.0 opens the resume picker in under 1 second, while 0.125.0 consistently takes about 8-10 seconds.

Test environment:

cwd: /home/lia
active JSONL files under ~/.codex/sessions: 29
active sessions directory size: 265M
visible state DB rows: 38
current stable after test: codex-cli 0.125.0

Measurement method:

  • Ran codex resume --no-alt-screen from /home/lia.
  • Measured time until resume picker list rows became visible.
  • Did not actually resume a session.
  • For 0.123.0, the CLI first showed an update prompt (0.123.0 -> 0.125.0). I selected Skip and excluded that update prompt time from the picker timing.
  • For model isolation, I also tested 0.125.0 with -m gpt-5.4.

Results:

0.125.0, default config model gpt-5.5:
run 1: 8.241s
run 2: 8.031s
run 3: 8.180s

0.123.0, forced model gpt-5.4:
run 1: 0.189s
run 2: 0.575s
run 3: 0.551s

0.125.0, forced model gpt-5.4:
run 1: 10.612s
run 2: 8.452s
run 3: 8.257s

Conclusion:

This looks like a CLI-side resume picker regression, not a model issue and not merely an unavoidable consequence of having a larger local session history.

The key comparison is:

0.123.0: under 1s
0.125.0: about 8-10s

Forcing gpt-5.4 on 0.125.0 remains slow, so the regression does not appear to be caused by gpt-5.5.

After the test, I restored the CLI to:

codex-cli 0.125.0
chalgoon9 · 4 months ago

Additional investigation after locally testing rust-v0.125.0:

This does not look like just “large session history is slow”. Before the recent CLI update, codex resume opened in roughly a few seconds for the same retained session set, and in an A/B downgrade test I measured 0.123.0 at about 0.19s, 0.57s, 0.55s to show the picker rows. With 0.124.0 / 0.125.0 the same measurement is around 8s+.

The main code-path difference I found is that 0.124+ added a use_state_db_only path for thread listing, but the TUI resume paths still pass false:

  • codex-rs/tui/src/resume_picker.rs::thread_list_params(...)
  • codex-rs/tui/src/lib.rs::latest_session_lookup_params(...)

Current 0.125.0 behavior for codex resume is therefore still:

thread/list use_state_db_only=false
-> filesystem / JSONL scan
-> scan-and-repair / reconcile rollout metadata
-> then return list results

This is especially costly because resume applies metadata filters such as source kind, provider, cwd, and archived=false. In 0.125.0, filtered listings go through the heavier reconcile path before returning.

I built a local experimental 0.125.0 binary and changed only the resume picker / latest-session lookup to use use_state_db_only: true. That reduced the measured picker-row time from about 8s+ to about 4.5s-4.8s, confirming that the JSONL scan-and-repair path is a large part of the regression.

There was also a separate startup latency source in my PTY environment: synchronous terminal capability/color queries before the first screen draw. Instrumentation showed roughly:

supports_keyboard_enhancement(): ~2s
terminal_palette::default_colors(): ~2s

Setting CODEX_TUI_DISABLE_KEYBOARD_ENHANCEMENT=1 on the installed 0.125.0 partially improved startup, but did not fix the JSONL scan cost. In a local build where I combined both changes:

  1. codex resume uses use_state_db_only: true
  2. startup avoids the blocking terminal capability/color queries before first draw

I measured:

patched 0.125.0 run 1: list visible 0.68s
patched 0.125.0 run 2: list visible 0.49s
patched 0.125.0 run 3: list visible 0.53s

So the practical fix direction seems to be:

  • Make codex resume / resume --last use the SQLite state DB as the primary listing source (use_state_db_only=true) instead of blocking on JSONL scan-and-repair.
  • If repair/backfill is still needed, run it as a fallback/background maintenance path rather than blocking the first picker page.
  • Separately, avoid or defer blocking terminal queries before the first TUI draw, because non-answering terminals/PTYs can add fixed multi-second startup latency.

This preserves large retained session histories while restoring the pre-regression codex resume behavior.

etraut-openai contributor · 4 months ago

This will be addressed in the next release.