Desktop 1.30096.1: PR status icons missing from session list after update

Confirming on a second machine. Same desktop build, newer CLI, different Darwin version — so the CLI bump does not fix it.

Environment

• Desktop app: 1.30096.1 (same build as the report)
• CLI: 2.1.227 (reporter was on 2.1.226)
• OS: macOS 26.4.1 (Darwin 25.4.0; reporter was Darwin 25.5.0)
• gh auth status: logged in, token valid

Symptom — identical. No open/merged PR icons on any session in the Code tab sidebar. Updating the app and doing a full restart did not restore them.

The PR data is reachable, so this looks display-side rather than a fetch or auth failure. On this machine, four sessions in the sidebar correspond to pull requests that are open right now — including one whose PR was created from within that very session about an hour ago. gh pr view resolves every one of them from the same machine, same shell, without error. So the state is current and available locally; the sidebar is not rendering it.

One detail that may help narrow it: the session rows still render their small status dots (amber / blue / hollow outline). Whatever those encode is unaffected. It is specifically the open/merged PR indicator that is gone, not the whole indicator column — which would point at the PR overlay rather than the row rendering as a whole.

Happy to grab logs or run something specific if that would help.

Confirming as well, on a third machine.

Environment

• Desktop app: 1.30096.1 (194d93) — same build as both prior reports
• OS: macOS 26.5.2 (Darwin 25.5.0) — same Darwin kernel as the original report, different from the second commenter's 25.4.0

Symptom — identical: no open/merged PR icons anywhere in the Recents/session list, including sessions I know are linked to open PRs. The other status indicators next to each session are unaffected — it's specifically the PR overlay that's missing, which lines up with @noahwsmith's read that this is display-side rather than a fetch/auth issue.

Happened to me as well. This is a horrible regression as this was a major part of my flow. I used to see the session list and the PR status was my way of knowing which is done, which is waiting for a review, which is in draft etc.

Fourth machine, and this one narrows it in two ways.

Environment

• Desktop app: 1.30096.5 — a newer point release than the 1.30096.1 in all three reports above. Still broken, so .5 did not fix it.
• CLI: 2.1.221 — older than the reporters (2.1.226 / 2.1.227). Combined with theirs, the failure spans 2.1.221 → 2.1.227, which rules the CLI out as the variable.
• OS: macOS 26.4 (Darwin 25.4.0), arm64
• gh 2.96.0, auth valid (scopes: gist, read:org, repo, workflow)

Symptom — identical. No open/merged PR icons on any session in the Code tab sidebar. Other status dots render normally.

Fresh repro: opened a draft PR from inside a session minutes ago. gh pr view resolves it from the same shell; the session row shows no PR icon. Consistent with the display-side read above.

Note the session is in a git worktree, though I doubt that's the trigger given the other reports.

Fifth machine. Same symptom, but this one widens the version span considerably and rules out two hypotheses I haven't seen tested above.

Environment

• Desktop app: 1.30096.5
• CLI: 2.1.104 — substantially older than every prior report (2.1.221 / 2.1.226 / 2.1.227)
• OS: macOS 15.7.4 (Darwin 24.6.0), arm64 — a full major version older than the others (26.4 / 26.5.2, Darwin 25.4.0 / 25.5.0)
• gh 2.92.0, auth valid (scopes: gist, read:org, repo, workflow)

Combined with the reports above, the failure now spans macOS 15.7.4 → 26.5.2, CLI 2.1.104 → 2.1.227, and gh 2.92.0 → 2.96.0. OS version, CLI version, and gh version are all ruled out as the variable. The one constant is the desktop build.

Symptom — identical. No open/merged PR icons on any session. The other status dots (amber / blue / hollow) render normally, matching @noahwsmith's read that this is the PR overlay specifically rather than the row.

Ruled out: gh not resolvable from the app's PATH. Worth eliminating explicitly, since GUI apps on macOS don't inherit shell PATH. On this machine gh lived in ~/bin, which is not in /etc/paths — so the app genuinely could not have found it, and this looked like a promising cause. I symlinked it into /usr/local/bin/gh, verified resolution under a clean GUI-equivalent environment:

env -i PATH=/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin which gh
→ /usr/local/bin/gh

then fully quit and relaunched (confirmed the process start time was after the symlink). No change. So the icons stay missing even when gh is unambiguously on the app's default PATH.

Ruled out: the feature being intentionally removed in this build. Contents/Resources/app.asar in 1.30096.5 still contains the relevant symbols — pullRequest (17 occurrences), pull_request (4), mergeable (8), and a gh pr invocation. The code ships; it just produces no output. Consistent with a regression rather than a removal.

Ruled out: a corrupted update. The Squirrel/ShipIt log for the update logs Installation completed successfully and a clean relaunch, identical in shape to the two prior updates on this machine that left the icons working.

Also confirming the negative on config: there is no setting governing this in either ~/.claude/settings.json or the desktop config.json — the latter contains no GitHub-related keys at all, so there's nothing for a user to have toggled off.

Happy to run anything specific on an older-OS machine if that's a useful contrast to the 26.x reports.