Resume picker and name-based resume appear to use session_index.jsonl thread_name, not state_5.sqlite title

What version of Codex CLI is running?

codex-cli 0.117.0

What subscription do you have?

ChatGPT Plus

Which model were you using?

gpt-5.4 xhigh fast

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

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

Windows Terminal 1.23.20211.0, running WSL2 Ubuntu

What issue are you seeing?

Session renaming is not reflected consistently in codex resume --all, and direct resume by renamed session name may fail.

I renamed a session with /rename, but the resume picker did not reliably show that renamed name. Instead it appeared to show the conversation preview / initial prompt text. Direct resume by the renamed name also failed.

Example failures:
``
codex resume "Codex Session Audit and Renaming" --no-alt-screen
ERROR: No saved session found with ID Codex Session Audit and Renaming. Run codex resume` without an ID to choose from existing sessions.

codex resume "CODEX SESSIONS OVERVIEW AND RENAMING" --no-alt-screen
ERROR: No saved session found with ID CODEX SESSIONS OVERVIEW AND RENAMING. Run codex resume without an ID to choose from existing sessions.

### What steps can reproduce the bug?

1. Start or resume an interactive Codex CLI session.
  2. Rename it with `/rename <SOME_HUMAN_READABLE_NAME>`
  3. Exit the session.
  4. Run: `codex resume --all`
  5. Observe that the picker may still show a conversation snippet / initial
     prompt instead of the renamed session name.
  6. Then try: `codex resume "SOME_HUMAN_READABLE_NAME" --no-alt-screen`
  7. Observe that direct resume by the renamed name may fail with “No saved
     session found”.

### What is the expected behavior?

I expect the resume picker to show the renamed session label consistently, and `codex resume "<name>"` to work using that renamed label.

### Additional information

From local inspection on my machine, there seem to be at least two separate session-name stores:

  - ~/.codex/state_5.sqlite
      - table: threads
      - field: title
  - ~/.codex/session_index.jsonl
      - field: thread_name

On my system, the practical behavior was:

  - changing title alone did not make codex resume --all show the renamed session labels
  - adding/updating thread_name in session_index.jsonl did make the picker show the session names
  - after that, codex resume "<thread_name>" also worked

That suggests either:

  - /rename is writing metadata that the picker is not consistently using
  - the picker is reading from session_index.jsonl while other code paths look at state_5.sqlite
  - or there is a cache / sync bug between the two stores

A minimal redacted example of the metadata that fixed the picker locally was:

`{"id":"THREAD_ID","thread_name":"Human-friendly session name","updated_at":"2026-03-30T19:08:16.651546572Z"}`

  I also noticed the current public slash-command docs do not clearly document /rename, which made this harder to diagnose.

A more concrete local reproduction based on what I inspected:

  1. Rename a session in the TUI with /rename.
  2. Check local metadata.
  3. You may find naming information split across:
      - ~/.codex/state_5.sqlite
      - ~/.codex/session_index.jsonl
  4. In my case:
      - threads.title in state_5.sqlite did not control what codex resume --all displayed.
      - thread_name in session_index.jsonl did appear to control the visible picker label and name-based resume.
  5. After adding/updating thread_name entries in ~/.codex/session_index.jsonl, the picker started showing the expected names and direct resume by name started working.