New proposal (related to `#3600`): Add `codex continue` to resume latest work in current directory

[Nhahan]

What feature would you like to see?

Currently, codex resume helps pick up from past work, but it is not always convenient when working across multiple repositories. I propose that codex continue should automatically resume the most recent Codex work in the current directory. This would make it consistent with the idea of codex resume, but simpler and more intuitive for ongoing local work.

Are you interested in implementing this feature?

Yes, I’d like to work on it.

Additional information

Related to Issue #3600, but focuses on adding codex continue to resume the latest work in the current directory.

[lox]

I'd love to see this as well, also happy to implement.

[dedrisian-oai]

codex resume --last works the same way! You could add an alias too, if you want it simpler.

Closing the issue for now.

[Nhahan]

@dedrisian-oai
Thanks for the quick reply! I think there’s a misunderstanding about the scope.
codex resume --last resumes the latest Codex session globally (across all directories on the machine).
My request was to resume the latest session within the current directory/workspace only.

Concretely, I’m proposing a UX like:

• codex continue → resume the most recent session whose workspacePath (or equivalent) matches the current directory (or its subdir).
• If none exists, fall back to a helpful message (or optionally prompt to list sessions in this directory).

Why this matters:

• When working across multiple repos in parallel, --last often resumes an unrelated repo’s session.
• Users expect “continue” in a folder to continue that folder’s work, mirroring how many CLI tools scope to CWD by default.

Possible designs (any of these would solve it):

• New subcommand: codex continue = “resume last session in CWD”
• New flag: codex resume --last-in-dir or codex resume --continue
• or maybe like Scope flag: codex resume --last --scope=dir (default: global)

[lox]

I have been using this implementation in my fork for a week or so, along with a fix to sort by mtime not ctime, it works well:

#4604

[williamhrs]

this would be awesome

[Nhahan]

Please check #4545

cc. @dedrisian-oai