What version of Codex CLI is running?
codex-cli 0.128.0
What subscription do you have?
ChatGPT Pro
Which model were you using?
gpt-5.5
What platform is your computer?
Darwin 25.3.0 arm64 arm
What terminal emulator and version are you using (if applicable)?
cmux 0.63.2 (79) [179b16ce6]
What issue are you seeing?
codex fork --last appears to ignore the default cwd filtering used by nearby session-selection flows.
For local sessions, codex resume --last selects the latest session for the current cwd unless --all is passed. The fork picker also applies cwd filtering by default unless --all is passed.
However, the local codex fork --last path appears to pass no cwd filter when looking up the latest session. As a result, running codex fork --last from one project can select and fork a newer session from a different project.
This makes codex fork --last behave like codex fork --last --all with respect to cwd filtering.
What steps can reproduce the bug?
A minimal scenario is:
- Create or have a recent Codex session in project A.
- Create or have an older Codex session in project B.
cd into project B.
- Run:
Expected target would be the latest session for project B.
Current behavior appears to allow the latest session from project A to be selected instead, because the local fork --last lookup does not pass a cwd filter.
From code inspection:
resume --last uses latest_session_cwd_filter(...).
- The fork picker also applies cwd filtering by default unless
--all is passed.
- The local
fork --last branch passes None as the cwd filter.
What is the expected behavior?
For local sessions, codex fork --last should mirror codex resume --last and the fork picker default behavior:
codex fork --last should select the latest session for the current cwd.
codex fork --last --all should select the latest session across all cwd values.
This would keep --all as the explicit opt-in for global session selection.
Additional information
I searched for existing issues/PRs around fork --last, cwd filtering, latest session selection, and resume/fork/history cwd behavior, and I did not find an exact duplicate.
Related but different items:
A narrow fix direction would be to make the local fork --last path use the same latest_session_cwd_filter(...) helper as resume --last, while preserving --all and remote cwd override behavior.
What version of Codex CLI is running?
codex-cli 0.128.0
What subscription do you have?
ChatGPT Pro
Which model were you using?
gpt-5.5
What platform is your computer?
Darwin 25.3.0 arm64 arm
What terminal emulator and version are you using (if applicable)?
cmux 0.63.2 (79) [179b16ce6]
What issue are you seeing?
codex fork --lastappears to ignore the default cwd filtering used by nearby session-selection flows.For local sessions,
codex resume --lastselects the latest session for the current cwd unless--allis passed. The fork picker also applies cwd filtering by default unless--allis passed.However, the local
codex fork --lastpath appears to pass no cwd filter when looking up the latest session. As a result, runningcodex fork --lastfrom one project can select and fork a newer session from a different project.This makes
codex fork --lastbehave likecodex fork --last --allwith respect to cwd filtering.What steps can reproduce the bug?
A minimal scenario is:
cdinto project B.Expected target would be the latest session for project B.
Current behavior appears to allow the latest session from project A to be selected instead, because the local
fork --lastlookup does not pass a cwd filter.From code inspection:
resume --lastuseslatest_session_cwd_filter(...).--allis passed.fork --lastbranch passesNoneas the cwd filter.What is the expected behavior?
For local sessions,
codex fork --lastshould mirrorcodex resume --lastand the fork picker default behavior:codex fork --lastshould select the latest session for the current cwd.codex fork --last --allshould select the latest session across all cwd values.This would keep
--allas the explicit opt-in for global session selection.Additional information
I searched for existing issues/PRs around
fork --last, cwd filtering, latest session selection, and resume/fork/history cwd behavior, and I did not find an exact duplicate.Related but different items:
thread/list, butcodex fork --lastappears to remain unaffected.resume --lastcwd filtering/path normalization and supports the expectation that--lastshould match picker filtering.A narrow fix direction would be to make the local
fork --lastpath use the samelatest_session_cwd_filter(...)helper asresume --last, while preserving--alland remote cwd override behavior.