The Pull Requests Page

The Review pane follows one request — the one on the branch you're standing on. The Pull Requests page is the other half: every request across every repository you have open in Codemux, grouped by what actually needs you.

It's a full-screen destination like Workspaces or Automations. Esc closes it — unless your cursor is in a textarea or a dialog is open, so a half-written review is never lost to a stray keypress.

Getting There

• Sidebar footer — the pull-request icon.
• Command palette — the Pull requests command (also matches pr, prs, review, merge request, incoming).
• pr mode in the palette — type pr and the palette narrows to loaded requests only, ranked by number, title, repo, and author. pr 285 puts #285 first. Selecting one opens the page at that request.
• Clicking a request URL anywhere in the app — see In-app links.
• Incoming rows in the Review pane, and the Open button on a toast.

The Badge

The sidebar icon carries a count, capped at 9+, and its tooltip reads "Pull requests — 3 waiting on you".

It counts exactly two things:

1. A request where a review is requested from you.
2. One of your own requests whose checks are failing.

Nothing else. Opening the page marks those as seen, so the badge drops to zero while you're actually looking at them, and only comes back when something new arrives.

Triage Groups

Review-requested beats authorship, so your own PR that someone asked you to review still sorts to the top group.

Watching is collapsible and folded by default — captioned "Repositories you have open but aren't involved in." and rendered in denser rows — unless it's the only group with anything in it. Rows are newest-first within each group.

Searching and Filtering

The search field accepts free text plus filters:

The placeholder shows the shape: Search, or is:draft ci:failing. A separate dropdown switches between Open, Closed, and All.

The footer reports coverage honestly — "14 repositories · 2 unreachable" — and the list renders at most 200 rows, saying so explicitly: "Showing the first 200 of 341."

Rows

Each row carries a CI dot (dashed for drafts, a spinner while pending, red or green once known, dim before the rollup lands), the title, a Draft chip, a state label (changes requested, ready to merge, merged, closed), and a meta line: host mark, #N / !N, repo, author, "checked out" when you have it locally, +adds −dels, and age.

Hover or focus a row for Check out (creates a worktree) or Switch (jumps to the workspace that already has it).

The list holds still while you use it

A background poll that wants to re-sort the list won't, as long as your pointer or keyboard focus is in it. Rows the poll wanted to move get a small ember dot instead — "Updated — the list will re-sort when you're done" — so the row under your cursor is always the row you click.

A failed refresh raises a strip — "The latest refresh failed · showing the list from 6m ago" with Retry — and leaves every row in place.

Reading Several at Once

The right side of the page is a tab strip of the requests you've opened. Each tab has its own status dot, middle-click closes it, and a + picker offers everything loaded. The detail column below is the same surface as the Review pane — header, Summary / Timeline / Code, action bar. See Reviewing & Merging.

Two things worth knowing:

• Drafts here are separate from the panel's. The same request can have two independent half-written reviews — one in the workspace panel, one on this page — and neither clobbers the other.
• A merged request stays readable in its tab even after it drops out of the Open filter.

In-app Links

A GitHub /pull/N or GitLab /-/merge_requests/N URL for a repository you have open routes to this page instead of your browser. Trailing /files, /commits, query strings, and fragments are all tolerated.

Three ways out of that:

• Shift-click the link.
• Settings → Source Control → Links → "Open pull request links in the browser".
• Have no project open for it — then it goes to the browser with a toast explaining why: "Opening this pull request in the browser — acme/web isn't a project you have open in Codemux."

Self-hosted instances are only intercepted if you've declared them under Self-hosted servers. Buttons already labelled Open in browser are never intercepted.

Toasts

Exactly two events raise a toast, app-wide:

• Review requested · acme/web#285 — the title as the description, with Open.
• CI failed on acme/web#285 — the failing check's name as the description, with Fix, which hands that specific check to an agent. It falls back to Open when the check name can't be fetched.

Neither fires from the snapshot carried over from your last session, neither re-fires while the condition persists, and a request that arrives already-red is never announced — so opening Codemux in the morning doesn't bury you in toasts about things you already knew.

Related

• Pull & Merge Requests — the Review pane and per-host support
• Reviewing & Merging — verdicts, line notes, threads, merging
• Command Palette — pr mode