Show PRs from all repositories and worktrees touched by a CLI thread

Open 💬 1 comment Opened Aug 12, 2026 by jerboy

What variant of Codex are you using?

CLI (TUI)

What feature would you like to see?

I would like the existing pull-request-number status-line item to show open pull requests from every Git checkout that is relevant to the current thread, rather than only the pull request associated with the current working directory.

A thread can interact with more than one checkout in several common workflows:

Codex or the user creates multiple Git worktrees for parallel changes.
Commands run with a cwd in another worktree of the current repository.
Commands run in a different repository during the same thread.
A resumed thread contains historical command executions from those directories.

The status line should discover pull requests from:

The current thread cwd.
Working directories used by command-execution items in the current thread, including replayed history.
All worktrees belonging to repositories identified by those directories.

When multiple pull requests are found, the existing single-line footer could render compact labels such as:

PR #123, PR #456

For pull requests from different repositories on the same host:

openai/codex#123, example/api#456

For different hosts, the host could also be included. Each label should link independently to its own pull request.

This should not increase the footer height or change the default status-line configuration. Existing git-branch and branch-changes items should remain scoped to the current cwd.

Additional information

The current pull-request-number lookup is useful for a single checkout, but it becomes incomplete during a long-running thread that coordinates several worktrees or projects. A pull request created in a sibling worktree can remain invisible even though it is part of the active conversation.

To keep the lookup bounded and avoid affecting TUI responsiveness, a possible implementation would:

Track only directories observed from the thread cwd and command execution cwd fields; do not scan arbitrary workspace roots or paths mentioned only in text.
Prioritize the current cwd, then touched directories in most-recently-used order, then automatically discovered worktrees.
Cap the number of checkouts, for example at 16.
Limit concurrent pull-request probes, for example to 4.
Refresh after session/configuration changes, cwd changes, and turn completion or interruption rather than polling continuously.
Omit failed probes and non-open pull requests on a best-effort basis.
Deduplicate pull requests by normalized URL.
Ignore stale asynchronous results after a thread or cwd change.

I have a working proof of concept with tests and an insta snapshot here:

The proof of concept keeps the footer single-line and gives every PR label an independent OSC 8 hyperlink.

I understand that external code contributions are by invitation only. I am filing this issue first to ask whether the behavior and proposed scope align with the maintainers intended direction, and whether the team would be willing to invite a pull request if the approach is acceptable.

Related issues:

#23473: current PR lookup not rendering in some environments
#30255: making the current PR number clickable
#22697: additional Git-related status-line items

View original on GitHub ↗

1 Comment

jdcodes1 · 9 days ago

Mapping this onto the current code: the probe is single-cwd by design — status_line_git_summary(runner, cwd) runs open_pull_request + diff stats against exactly one directory and is cached per cwd (https://github.com/openai/codex/blob/1f41cc5d92/codex-rs/tui/src/branch_summary.rs#L117-L135). So the feature is (a) a source of candidate directories and (b) a fan-out with the caps you proposed.

For (a), your "track only observed cwds" rule has a clean anchor: exec-tool invocations carry an explicit per-call cwd, and worktrees of the current repo are enumerable cheaply via git worktree list --porcelain — both bounded, no text scanning. For (b), the existing per-cwd cache generalizes to a keyed map with MRU eviction at your proposed cap; the refresh triggers you list (turn completion, cwd/config change) match events the chatwidget already observes for the current single-cwd refresh.

One design question worth settling early: presentation. The status line is one row — multiple PRs probably want #123 +2 (current-cwd PR plus a count) with the full list behind /status, rather than concatenating numbers into the strip.