Skip to content

codex fork --last ignores default cwd filtering and can fork a session from another project #20945

@chanwooyang1

Description

@chanwooyang1

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:

  1. Create or have a recent Codex session in project A.
  2. Create or have an older Codex session in project B.
  3. cd into project B.
  4. Run:
codex fork --last

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.

Metadata

Metadata

Assignees

Labels

TUIIssues related to the terminal user interface: text input, menus and dialogs, and terminal displaybugSomething isn't workingsessionIssues involving session (thread) management, resuming, forking, naming, archiving

Type

No type
No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions