TUI /resume omits directly resumable sessions after /goal continuation

Resolved 💬 1 comment Opened May 16, 2026 by 2c67cc18 Closed May 16, 2026

What version of Codex CLI is running?

Reproduces on:

codex-cli 0.130.0
codex-cli 0.131.0-alpha.22

What subscription do you have?

Pro

Which model were you using?

gpt-5.5 / high-reasoning goal sessions

What platform is your computer?

macOS Darwin 25.4.0 arm64 arm

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

Ghostty 1.3.1

What issue are you seeing?

Some valid local TUI sessions are missing from /resume. These sessions:

  • were started normally,
  • used /goal later,
  • have rollout JSONL files under ~/.codex/sessions,
  • have rows in ~/.codex/state_5.sqlite,
  • can be resumed directly with codex resume <thread_id>.

The same sessions are absent from the TUI /resume picker when Codex is opened in the matching project directory. This reproduces on both 0.130.0 and 0.131.0-alpha.22.

Related issues:

  • #21619: codex resume --all omits resumable sessions when first user_message is beyond scan limit
  • #20792: /goal-first sessions are missing from resume lists (closed as fixed)
  • #22557: The session is not saved when using /goal (closed as known/fixed)

This differs from the /goal-first case. A session can start normally, later become goal-driven, and then goal continuation / subagent-notification activity can leave the canonical event_msg user_message absent or too far into the rollout for picker/list indexing.

Sanitized local state:

id           title/preview  first_user_message  has_user_event  direct resume  in /resume
-----------  -------------  ------------------  --------------  -------------  ----------
thread A     no             no                  0               yes            no
thread B     yes            yes                 0               yes            no
thread C     yes            yes                 0               yes            no

For one affected session, the rollout exists but the first canonical user event is very late:

line ~7053: {"type":"event_msg","payload":{"type":"user_message","message":"<redacted>", ...}}

For another affected session, the first canonical user event is around line 234, just beyond the current filesystem head scan window.

The likely cause is that active goal continuation starts a turn from a hidden developer message instead of a normal user message. In current main, codex-rs/core/src/goals.rs creates the continuation input as a developer ResponseInputItem: https://github.com/openai/codex/blob/2abdeb34d5b7a0bbdf082ce8be1d5dae6c645ffd/codex-rs/core/src/goals.rs#L1314-L1323

A valid resumed goal session can contain session metadata, developer messages, tool work, assistant output, compaction records, and subagent notifications before any EventMsg::UserMessage.

The list path then drops it:

  • TUI /resume uses the app-server thread/list flow for the current cwd.
  • SQLite listing adds AND threads.first_user_message <> ''.
  • Filesystem listing requires summary.saw_session_meta && summary.saw_user_event.
  • saw_user_event is only set for RolloutItem::EventMsg(EventMsg::UserMessage(_)).
  • State extraction intentionally ignores ResponseItem::Message { role: "user" }, so early user-role response items do not count as a first user message.

What steps can reproduce the bug?

  1. Start a normal TUI session in a project directory.
  2. Use /goal later in that session.
  3. Let Codex continue the active goal across turns/resumes.
  4. Exit Codex.
  5. Reopen Codex in the same project directory.
  6. Open /resume.
  7. Search by the directly resumable thread id or visible title text.
  8. Observe that the session is absent.
  9. Run codex resume <thread_id> and observe that direct resume succeeds.

This was also checked with alpha:

npx -y @openai/codex@alpha --version
# codex-cli 0.131.0-alpha.22

cd <affected-project>
npx -y @openai/codex@alpha
# open /resume and search for the directly-resumable thread ids

The sessions were still absent from /resume.

Useful diagnostics:

sqlite3 -header -column ~/.codex/state_5.sqlite \
  "select id,title,first_user_message,has_user_event,datetime(created_at,'unixepoch') created,datetime(updated_at,'unixepoch') updated
   from threads
   where cwd='<project cwd>'
   order by updated_at desc;"

rg -n '"type":"user_message"|Continue working toward the active thread goal|"role":"developer"|"role":"user"' \
  ~/.codex/sessions/<yyyy>/<mm>/<dd>/rollout-<timestamp>-<thread_id>.jsonl

What is the expected behavior?

Any local session that is directly resumable by ID and belongs to the current cwd should be discoverable in the TUI /resume picker.

For goal continuation sessions, Codex should have a listable preview even when the current/first active turn was created from a hidden developer goal-continuation prompt rather than a typed user message.

Acceptable preview sources could include:

  • existing first_user_message,
  • active/completed goal objective,
  • first assistant message,
  • fallback title such as Goal: <objective>.

Additional information

This overlaps with #21619, but the goal-specific trigger still reproduces on codex-cli 0.131.0-alpha.22.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗