›_ Codex Issues
Codex Issues / #36010

TUI /resume picker resets to Cwd filter after launching with codex resume --all

Open 💬 2 comments Opened Jul 29, 2026 by basiphobe

Summary

The in-session TUI /resume picker always starts with the Cwd filter selected. This happens even when Codex was launched through codex resume --all, so the behavior changes after entering a session: the startup picker can show all sessions, but the slash-command picker narrows back to the current working directory.

Environment

  • Codex CLI: 0.146.0
  • Surface: TUI

Steps to reproduce

  1. Create or keep interactive Codex sessions from at least two different working directories.
  2. Start Codex with:

``bash
codex resume --all
``

  1. Select or start a session.
  2. From inside the running TUI, enter:

``text
/resume
``

Expected behavior

The in-session /resume picker should make it straightforward to see the same all-session view available from codex resume --all. Reasonable fixes would include one of the following:

  • Default the in-session /resume picker to All.
  • Preserve the launch-time --all preference for later /resume usage in that TUI session.
  • Add a persisted/default picker-filter setting, similar to the existing persisted session picker view setting.
  • Add an explicit slash-command option such as /resume --all.

Actual behavior

The in-session picker opens in Cwd mode and only lists sessions whose stored session cwd matches the current session cwd. When the current cwd has only one matching session, the picker appears to show only the current session even though other sessions exist and can be listed through the all-session path.

Current workaround

After opening /resume, use the picker toolbar to switch the filter from Cwd to All. The filter control is focused initially, so the left/right arrow key toggles it in the current picker implementation.

Implementation notes

In rust-v0.146.0, the in-session slash-command path calls the resume picker with show_all hardcoded to false:

crate::resume_picker::run_resume_picker_from_existing_session_with_app_server(
    tui,
    &self.config,
    /*show_all*/ false,
    /*include_non_interactive*/ false,
    picker_app_server,
)

The picker initializes its filter mode from that value:

filter_mode: SessionFilterMode::from_show_all(show_all, filter_cwd.as_deref()),

The current config schema exposes tui.resume_cwd and tui.session_picker_view, but does not appear to expose a default Cwd/All filter preference for the picker.

View original on GitHub ↗

2 Comments

charle-z · 10 days ago

I reproduced this on current main and have a focused candidate fix in charle-z/codex at commit 5b832b92a5548fcf6fac229ce45b12d1246860a5 (fix/resume-picker-filter-continuity).

Root cause: codex resume --all passes show_all=true to the startup picker, but that launch-time preference is not retained by App; later AppEvent::OpenResumePicker hardcodes show_all=false, so in-session /resume silently narrows back to Cwd.

The patch keeps the launch-time resume scope in App and reuses it for later /resume calls. It deliberately does not change picker_cwd_filter(..., false, ...), so the Cwd candidate remains available and All -> Cwd still works. Provider/session-source filtering and fork behavior are unchanged.

Validation performed on the public branch:

  • real PTY: resume --all -> select session -> /resume reopens in All;
  • real PTY control: normal resume -> /resume remains Cwd-scoped;
  • All -> Cwd toggle still works;
  • revert-proof: changing only OpenResumePicker back to false restores the reported bug;
  • focused codex-tui picker test passes on Rust 1.95;
  • just fix -p codex-tui passes; Rust formatting check passes.

Branch: https://github.com/charle-z/codex/tree/fix/resume-picker-filter-continuity

charle-z · 10 days ago

Follow-up after revalidating this issue and the current upstream state on 2026-08-17.

There has still been no maintainer evaluation visible on this issue: it has no assignee, the only existing comment is my previous technical report, and there are currently 0 linked pull requests.

The candidate fix is still publicly available and unchanged:

I revalidated it against the current openai/codex:main (2eee483e49f88b868f67364134a658b3298e6c14). Upstream has advanced independently again, but the fork still has a unique contribution and valid shared history/merge-base; the compare remains a valid cross-repository contribution. No rebase, force-push, or artificial merge commit is needed.

Root cause and intended invariant remain narrow:

  • codex resume --all correctly starts the initial picker with show_all=true;
  • App did not retain that launch-time resume scope;
  • later AppEvent::OpenResumePicker hardcoded show_all=false, silently narrowing in-session /resume back to Cwd;
  • the fix stores the launch-time resume picker scope in App and reuses it for later /resume within that TUI lifecycle;
  • normal launches remain Cwd-scoped;
  • picker_cwd_filter(..., false, ...) intentionally remains unchanged so All -> Cwd still works;
  • provider/session-source filtering, fork behavior, and remote semantics are unchanged.

The six touched files are only the propagation/fixture surface: app.rs, app/event_dispatch.rs, app/startup.rs, lib.rs, app/test_support.rs, and app/tests.rs.

Validation completed on the exact public candidate includes:

  • focused resume-picker test passing;
  • real PTY regression: resume --all -> select session -> /resume reopens in All;
  • real PTY control: normal resume -> /resume remains Cwd;
  • All -> Cwd toggle still works;
  • revert-proof: restoring only the event argument to false reproduces the reported regression;
  • just fix -p codex-tui/Clippy completed without patch-attributable findings;
  • Rust formatting and git diff --check pass;
  • an independent hostile review traced launch propagation, in-session /resume, normal Cwd, toggle behavior, fork/provider/session-source paths and found no blocking semantic issue;
  • unrelated suite failures observed during validation were reproduced on the clean base and were not caused by this patch.

I also attempted to open the upstream PR through the supported GitHub API path and through an authenticated gh path. GitHub rejects creation with 404/insufficient permissions, and the web UI states: "An owner of this repository has limited the ability to open a pull request to users that are collaborators on this repository." No PR was created.

If this approach is aligned with the maintainers' intended fix, could a maintainer either invite charle-z to open the PR, or take/cherry-pick 5b832b92a5548fcf6fac229ce45b12d1246860a5? I am happy to respond to review feedback or adjust the focused patch if requested.