›_ Codex Issues
Codex Issues / #21619

codex resume --all omits resumable sessions when first user_message is beyond scan limit

Open 💬 5 comments Opened May 8, 2026 by muzahidulislamhadi
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What happened?

A valid local Codex CLI session is omitted from codex resume --all, even though it can be resumed directly by session ID.

Direct resume works:

codex resume 019e029c-b1e9-7e31-992e-df4638cf8ee8

But the same session does not appear in:

codex resume --all
codex resume --all --no-alt-screen

Searching inside the picker by UUID or title also returns no result.

Environment

  • Codex CLI: 0.129.0
  • Package: @openai/codex@0.129.0
  • OS: Linux
  • Session source: cli
  • Model provider: openai

Evidence

The session JSONL exists:

~/.codex/sessions/2026/05/07/rollout-2026-05-07T13-24-44-019e029c-b1e9-7e31-992e-df4638cf8ee8.jsonl

The local SQLite state index contains the session:

id: 019e029c-b1e9-7e31-992e-df4638cf8ee8
title: Review again and return FINAL REPORT!!
cwd: /path/to/project
archived: 0
has_user_event: 0
source: cli
model_provider: openai

The JSONL has a valid session_meta, and direct resume succeeds. However, the first actual user_message appears late in the file:

line 424: {"timestamp":"2026-05-07T13:57:10.370Z","type":"event_msg","payload":{"type":"user_message","message":"Review again and return FINAL REPORT!!", ...}}

Suspected cause

This appears related to #9501 and #9512, but the current fix still seems bounded by the picker scan limits:

HEAD_RECORD_LIMIT = 10
USER_EVENT_SCAN_LIMIT = 200

Because the first user_message is at line 424, the session remains outside the scan window and is omitted from the resume picker/list/search path.

Expected behavior

Any session that can be resumed directly by ID and exists in the local session index should appear in codex resume --all, or at least be searchable by UUID/title in the picker.

Actual behavior

The session is omitted from codex resume --all and cannot be found via picker search, despite being directly resumable by ID.

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 3 months ago

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

  • #20165
  • #20792

Powered by Codex Action

Necmttn · 2 months ago

The picker should be able to list a session from metadata before deeply scanning the JSONL.

Use the state index / file metadata for session id, title, cwd, source, archived flag, and timestamp; then lazily scan deeper content when the row is opened or searched. A late first user_message should affect preview quality, not resumability.

has_user_event=false can be shown as a state, but it should not hide a directly resumable session.

---

_Generated with ax._

mattezell · 2 months ago

I can reproduce this on Codex CLI 0.142.2 with a session originally written by 0.141.0.

Observed behavior:

codex resume --all --no-alt-screen

The picker only lists my current session, but the older session is present in the SQLite thread inventory and is directly resumable by UUID:

codex resume 019eeafc-02e9-7882-8fb1-52a039242e48

That direct resume opens correctly and prompts whether to use the recorded session cwd:

/home/matt/w/procedural-space/codex-procedural-space

Local DB row for the affected thread:

id: 019eeafc-02e9-7882-8fb1-52a039242e48
source: cli
thread_source: user
cwd: /home/matt/w/procedural-space/codex-procedural-space
title: I've approved permissions - proceed
has_user_event: 0
archived: 0
cli_version: 0.141.0
rollout_path: /home/matt/.codex/sessions/2026/06/21/rollout-2026-06-21T11-20-44-019eeafc-02e9-7882-8fb1-52a039242e48.jsonl

codex doctor --json reports rollout/DB parity as OK:

active rollout files: 4
rollout DB active files: 4
rollout DB active rows: 4
rollout DB missing active rows: 0
rollout DB stale rows: 0
rollout DB scan errors: 0

This case also matches the scan-limit theory: the first event_msg with payload.type = user_message is at line 229, just beyond the suspected USER_EVENT_SCAN_LIMIT = 200. Earlier response_item records with role = user exist at lines 4 and 6, but the state row still has has_user_event = 0, and the picker omits the session even though direct resume succeeds.

So this still appears present in 0.142.2: a late first event_msg.user_message affects picker visibility/search, but it should not make an indexed, directly resumable CLI/user session disappear from resume --all.

mattezell · 2 months ago

I put together a concrete patch for this on a fork branch:

https://github.com/mattezell/codex/tree/fix/resume-picker-previewless-sessions

Branch commit:

24b5388636 Fix listing sessions without early previews

Summary of the proposed fix:

  • raw rollout listing now treats valid session_meta as sufficient for listability, even when no preview-bearing event is found inside the bounded scan window
  • SQLite thread listing no longer filters out rows with an empty preview
  • added a rollout regression where the first event_msg user_message appears after 225 records, beyond the current scan window
  • added a state DB regression for listing rows without preview or first_user_message metadata

This preserves degraded display quality for such rows while keeping directly resumable sessions visible in resume --all.

I attempted to open a PR from mattezell:fix/resume-picker-previewless-sessions to openai:main, but GitHub returned a CreatePullRequest permission error. The repo contribution guide also says external PRs are invitation-only, so sharing the patch here for maintainer use.

shleder · 14 days ago

Your line-424 evidence is a useful boundary case: the rollout and SQLite row exist, direct UUID resume works, but the bounded picker scan makes the session effectively disappear.

I’m testing Codex Rescue against local-session discovery failures like this. It is local-first, reads rollouts without changing them, and won’t modify the Codex index or try to “repair” the picker. The useful question here is whether it consistently discovers the hidden session and reports its state despite the late first user event.

If you still have the case, could you run:

pipx install codex-rescue==0.1.0a3
codex-rescue sessions
codex-rescue doctor --latest

Sanitized output is sufficient—please don’t publish raw JSONL, SQLite data, prompts, filesystem paths, or secrets.

https://github.com/shleder/codex-rescue