Skip to content

codex resume <name> can fail after a fresh thread is auto-named, and unsaved name entries can shadow older saved sessions #15943

Closed
Closed
codex resume <name> can fail after a fresh thread is auto-named, and unsaved name entries can shadow older saved sessions#15943
Assignees
etraut-openai
Labels
TUIIssues related to the terminal user interface: text input, menus and dialogs, and terminal displaybugSomething isn't working

Description

@paulbettner
paulbettner
opened on Mar 27, 2026

What version of Codex CLI is running?

codex-cli 0.116.0

What subscription do you have?

Unknown / not relevant to this bug

Which model were you using?

gpt-5.4

What platform is your computer?

Darwin 25.3.0 arm64 arm

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

Zed terminal (TERM=xterm-256color)

What issue are you seeing?

A fresh interactive Codex CLI session can print a resumable thread name before any resumable session data actually exists.

Example observed behavior:

  1. Start codex in a directory named smarty-pants

  2. Codex prints:

    Thread renamed to smarty-pants, to resume this thread run codex resume smarty-pants

  3. Exit before sending the first user message

  4. Run:

    codex resume smarty-pants

  5. Codex fails with:

    ERROR: No saved session found with ID smarty-pants. Run \codex resume` without an ID to choose from existing sessions.`

Underlying local state shows the thread name was indexed even though no resumable session exists yet:

  • ~/.codex/session_index.jsonl contains a thread_name entry for the new thread id
  • there is no rollout file for that thread under ~/.codex/sessions/...
  • there may also be no corresponding persisted thread row yet

This means the CLI can advertise a name-based resume command for a thread that is not actually resumable.

It also has a worse side effect: if there is an older saved thread with the same name, the newer unsaved name entry can win name lookup and block access to the older saved thread.

What steps can reproduce the bug?

Minimal repro:

  1. Create or enter a directory named smarty-pants
  2. Run codex
  3. Observe that Codex prints a resume hint using the thread name smarty-pants
  4. Exit before sending the first user message
  5. Run codex resume smarty-pants
  6. Observe that resume fails even though Codex just suggested that exact command

Shadowing repro:

  1. Have an older saved thread already named smarty-pants
  2. Start a new fresh CLI session in a directory that causes the new thread to also be named smarty-pants
  3. Exit before the first user message is persisted
  4. Run codex resume smarty-pants
  5. Observe that Codex resolves the newest unsaved name entry first instead of resuming the older saved thread

What is the expected behavior?

One of these should happen:

  • Codex should not suggest codex resume <name> until a resumable rollout actually exists
  • name-based resume should skip unresolved / unsaved name entries and fall back to the newest saved session with that name
  • ideally both

A fresh unsaved thread name should not block name-based access to an older saved session.

Additional information

This appears to come from thread names being appended to session_index.jsonl before rollout persistence exists, while name-based resume trusts the newest matching name entry.

A high-level fix direction would be either:

  • do not index thread names until the session has persisted resumable state
  • or make name-based lookup skip entries that do not resolve to a saved rollout path

A UI follow-up would be to stop printing a resume command in the rename confirmation until the session is actually resumable.

This seems related in spirit to #15870, but it is a different repro:

I have a tested local patch and regression tests for this if the Codex team wants a PR by invitation.

Activity

  1. github-actions
    added
    bugSomething isn't working
    CLIIssues related to the Codex CLI
    on Mar 27, 2026

  2. github-actions commented on Mar 27, 2026

    @github-actions
    github-actionsbot
    on Mar 27, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  3. paulbettner commented on Mar 27, 2026

    @paulbettner
    paulbettner
    on Mar 27, 2026
    Author

    I reviewed #15870, and I do not think this is a duplicate.

    #15870 is about early transport failure after a session ID is printed but no local resumable artifacts are persisted.

    This issue reproduces without transport failure:

    1. start a normal fresh interactive codex session in a directory like smarty-pants
    2. Codex auto-renames the thread and suggests codex resume smarty-pants
    3. exit before the first user message
    4. codex resume smarty-pants fails

    The distinguishing detail is that session_index.jsonl already contains the new thread_name, but there is still no saved rollout for that thread, so name-based resume resolves an unsaved entry.

    This also causes a separate shadowing bug: an unsaved latest name entry can block access to an older saved session with the same name.

    So this is not just “session shown before persistence”; it is specifically “name-based resume trusts unsaved thread-name index entries”.

  4. etraut-openai
    added
    TUIIssues related to the terminal user interface: text input, menus and dialogs, and terminal display
    and removed
    CLIIssues related to the Codex CLI
    on Mar 27, 2026

  5. raye-deng commented on Mar 27, 2026

    @raye-deng
    raye-deng
    on Mar 27, 2026

    Session name shadowing is a great catch. This falls into a pattern we see frequently with AI coding tools: state that's created optimistically but never validated.

    The name gets printed before the session is persisted — so the system tells the user 'here's how to resume' based on a promise, not a verified fact. When the user trusts that promise and tries to resume, they hit an opaque failure.

    This is structurally similar to a class of issues we've been cataloging in AI-generated code:

    1. Phantom imports — the AI references a package that looks real (passes type checking, passes tests) but doesn't exist on the registry
    2. Stale API paths — generated code calls an endpoint that was deprecated in a minor version bump, masked by version pinning in dev
    3. Context handoff failures — multi-session generation where Session 2 assumes Session 1 completed successfully without verification

    In all these cases, the system creates an artifact (an import, a session name, a cross-file reference) optimistically, and downstream consumers trust it without validation.

    A structural fix for the resume case might be to write the session metadata atomically with the name assignment — so the name only exists if the backing data also exists. That way, 'can I resume?' is always a valid question to answer.

    More broadly, adding a CI-level check that validates assumptions baked into AI-generated code (registry existence, API currency, cross-file consistency) catches these before they become production incidents. npx @opencodereview/cli scan . --sla L1 if anyone wants to see what that looks like.

  6. Alek2077 commented on Mar 27, 2026

    @Alek2077
    Alek2077
    on Mar 27, 2026

    Confirmed a related repro locally on codex-cli 0.117.0 on Linux/WSL.

    What I verified:

    • UUID resume works for the same saved sessions.
    • A single-word thread name can resolve successfully.
    • Some multi-word thread names fail with ERROR: No saved session found with ID ... even though the target session is already persisted.
    • In the failing cases, the saved rollout file exists under ~/.codex/sessions/....
    • In at least one failing case, there is also an exact matching thread_name entry in ~/.codex/session_index.jsonl.

    So this seems broader than only "unsaved thread name shadows older saved session". There may be an additional lookup bug affecting some thread names, especially multi-word names, and the regression appears reproducible on 0.117.0.

    Update: after rolling back from codex-cli 0.117.0 to 0.116.0, the same previously failing name-based resume command now works locally. That makes this look more like a 0.117.0 regression than a general long-standing lookup issue.

  7. etraut-openai
    self-assigned this
    on Apr 3, 2026
  8. etraut-openai
    added 2 commits that reference this issue on Apr 9, 2026

    Skip unsaved thread names during resume lookup

    6e9b14b

    Fix stale thread-name resume lookups (#16646)

    36586ea

  9. etraut-openai commented on Apr 9, 2026

    @etraut-openai
    etraut-openai
    on Apr 9, 2026
    Contributor

    Thanks for the bug report. This will be addressed in the next release.

  10. etraut-openai
    closed this as completedon Apr 9, 2026
  11. Oreoxp
    added a commit that references this issue on Apr 10, 2026

    Fix stale thread-name resume lookups (openai#16646)

    21274ae
  12. wangjiecloud
    added a commit that references this issue on Jun 27, 2026

    Fix stale thread-name resume lookups (openai#16646)

    7636138
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

TUIIssues related to the terminal user interface: text input, menus and dialogs, and terminal displaybugSomething isn't working

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions