codex resume --last can start a fresh session even when codex resume picker can continue the intended thread

[zio3]

What version of Codex is running?

codex-cli 0.118.0

What subscription do you have?

Plus

Which model were you using?

No response

What platform is your computer?

Windows

What issue are you seeing?

codex resume works as expected when I pick the intended prior session from the interactive picker, but codex resume --last starts what appears to be a fresh session instead of continuing that same session.

This does not look like an expected UX difference between picker mode and --last. From reading the open-source code, --last appears to apply additional filtering when resolving the latest session (for example cwd / source kind / model provider), and when that lookup fails the result is effectively a fresh session.

That makes resume --last behave very differently from what users usually expect from "resume the last session", especially when the plain resume picker can still find and continue the expected thread.

What steps can reproduce the bug?

1. Start a Codex session in a repository / workspace.
2. Exit Codex.
3. Run codex resume, choose the most recent expected session from the picker, and confirm that it resumes correctly.
4. Exit again.
5. Run codex resume --last from the same environment.
6. Observe that Codex starts what appears to be a fresh session instead of continuing the same thread.

What is the expected behavior?

codex resume --last should continue the same most recent session that a user would reasonably expect from the picker flow, or at minimum fail clearly instead of silently falling back to a fresh session.

Additional information

Related UX discussion: #4545

I think there are two separate concerns here:

1. Bug: resume --last can behave like a fresh session even though the picker can still resume the intended thread.
2. UX / semantics: users are likely to interpret --last as "resume the globally latest session" rather than "resume the latest session matching hidden filters".

Even if the filtering is intentional, silently landing in a fresh session seems wrong.

[github-actions]

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

• codex exec resume accepts nonexistent session ids and starts a new thread instead of failing #15539
• codex exec resume silently starts a new thread when given an ephemeral session id #15538
• thread/list filesystem fallback can hide older matching threads after hitting 10,000-file scan cap #16545

Powered by Codex Action

[etraut-openai]

resume --last is intended to use the same filtering logic as the default resume picker. resume --last also pairs with --all which eliminates some of the filters (notably, the cwd filter).

Can you say more about which differences you're seeing in filtering between resume --last and the resume picker?

[zio3]

Thanks, that clarified it.

I tested codex resume --last --all, and that behaves as I expected. It correctly restored the same session state after restarting Codex.

So it seems the behavior I was seeing is tied to the default filtered behavior of codex resume --last, rather than --last in general.

That said, from a user perspective, I think it is natural to expect codex resume --last to resume the same session that would be selected as the most recent one in codex resume.

Now that I understand the distinction, I can use --all when I want that behavior. Thanks for the clarification.

[zio3]

A correction to my earlier comment: my interpretation of --all was mistaken.

It was not that codex resume --last --all consistently gave me the behavior I wanted. It only appeared to do so in cases where the latest global session happened to match what I wanted to resume.

I think I found a more specific explanation for what I was seeing on Windows.

The resumed session path was shown as:

\\?\C:\Users\info\source\repos\TerminalHub

while my current working directory was:

C:\Users\info\source\repos\TerminalHub

So these appear to refer to the same directory, but with different path representations.

After reading the source more closely, it looks like resume --last goes through thread/list with a cwd filter, and that filter currently appears to compare paths directly in the app-server path:

• summary.cwd == expected_cwd

By contrast, the picker-side filtering appears to use normalized path comparison.

If that reading is correct, then on Windows this could explain why codex resume --last fails to match a session in the same directory when one side uses an extended path form like \\?\C:\... and the other uses the normal C:\... form.

So my current guess is that the issue may be a Windows path normalization mismatch in the cwd filter used by resume --last.

[zio3]

Here is the prompt I saw on Windows. The session directory is shown as \\?\C:\... while the current directory is shown as C:\..., even though they refer to the same location.

[etraut-openai]

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

[zio3]

Thanks for the quick fix and for closing the loop on this.

I appreciate the investigation and the Windows path normalization fix. I'm glad the issue was identified and addressed so quickly.