v0.61.0 PR feature adds ~600ms overhead per refresh (10x regression, no opt-out)

[Aayush9029]

Description

v0.61.0 introduced GitHub PR integration (#2781). On every startup and after every background fetch, lazygit now makes two GitHub GraphQL round-trips to fetch PR data. This adds ~600ms of overhead per refresh cycle — a 10x regression in post-fetch refresh time compared to v0.59.0.

There is no config option to disable this feature. It auto-activates if gh auth login has been run, which is true for most developers.

Reproduction

# Clone this repo (public, verifiable)
git clone https://github.com/jesseduffield/lazygit.git /tmp/lazygit-bench
cd /tmp/lazygit-bench
gh repo set-default jesseduffield/lazygit

# Run with debug logging
LOG_LEVEL=info lazygit --debug

# In another terminal, tail the log:
# tail -f ~/Library/Application\ Support/lazygit/development.log | grep -E "Fetched|Refresh took|git fetch"

Measurements

Methodology: ran each version in tmux with --debug flag, let it fully initialize for 8 seconds, killed the session, then extracted durations from lazygit's own debug log (~/Library/Application Support/lazygit/development.log). 3 sequential runs per version on the same machine, tested on this repo.

v0.61.0 (current)

Run	PR fetch #1	PR fetch #2	Final refresh
1	330ms (5 PRs)	264ms	506ms
2	359ms (5 PRs)	240ms	522ms
3	302ms (5 PRs)	431ms	696ms

v0.59.0 (baseline, no PR feature)

Run	PR fetch	Final refresh
1	N/A	58ms
2	N/A	56ms
3	N/A	57ms

Post-fetch refresh: ~575ms (v0.61.0) vs ~57ms (v0.59.0) — 10x slower.

Also confirmed on two private repos. The overhead is consistent (~250-350ms per GraphQL round-trip, 2 round-trips per refresh cycle) regardless of repo size or number of PRs returned.

Root cause

From the debug logs, the startup sequence is:

1. Initial async refresh → PR fetch Pressing space without any changes crashes lazygit #1 (GraphQL call, ~300ms)
2. git fetch --all completes → triggers sync refresh including pullRequests scope → PR fetch Correct gocui link #2 (~250ms)

The GraphQL round-trip is the bottleneck — even when fetching only 5 PRs, each call takes 250-430ms due to network latency. This runs on every refresh, not just startup.

Additionally, if remote.origin.gh-resolved is not set (which it isn't by default unless you run gh repo set-default), the PR fetch still takes ~300ms to fail and returns 0 PRs.

Suggestions

1. Add a config toggle (e.g. git.showPullRequests: false) — the original PR had one (enableGithubCli) but it was removed during review.
2. Cache PRs aggressively — skip re-fetching if the last fetch was < N seconds ago, especially on the post-git fetch refresh.
3. Don't fetch PRs if gh-resolved is not set — currently spends ~300ms failing silently.

Environment

• lazygit: v0.61.0 (Homebrew)
• macOS 26.4 (Apple Silicon, arm64)
• git 2.50.1 (Apple Git-155)
• gh 2.89.0
• Terminal: Ghostty

[stefanhaller]

I'm aware of that, but I don't see why it is a problem; please explain. Fetching PRs happens in the background, and it doesn't affect how fast the rest of the UI updates, so users shouldn't see a difference.

As you noticed, we did consider adding a config to disable the feature, but removed it during review because we couldn't see a reason why anybody would want to turn it off.

Additionally, if remote.origin.gh-resolved is not set (which it isn't by default unless you run gh repo set-default), the PR fetch still takes ~300ms to fail and returns 0 PRs.

Now this is a separate issue that may be worth discussing. If gh-resolved is not set, lazygit uses a number of fallbacks:

1. if there is exactly one remote, it uses it
2. otherwise, if there is a remote called "upstream", it uses it
3. otherwise, if there is a remote called "origin", it uses it
4. otherwise, it prompts the user for the base repository.

My guess is that in your case you are hitting point 3, but origin is not the base repository but your fork, and the upstream repo is called something else. Since this is probably a very common case, I'd consider removing that fallback and go straight from 2 to 4. Please let me know if I guessed right.

[Aayush9029]

Thanks for the quick reply! You're right that the first PR fetch is async. But the second one runs in sync mode and blocks the UI — from the debug log on a fresh clone of this repo:

{"msg":"refreshing all scopes in async mode"}                          ← first refresh, async ✓
{"msg":"Fetched 5 PRs in 307ms"}                                       ← first PR fetch (background)
{"msg":"git fetch --all --no-write-fetch-head (629ms)"}                ← background fetch completes
{"msg":"refreshing the following scopes in sync mode: branches,commits,remotes,tags,pullRequests"}  ← second refresh, sync
{"msg":"Fetched 5 PRs in 236ms"}                                       ← blocks here
{"msg":"Refresh took 507ms"}                                           ← total sync refresh

The pullRequests scope is included in the sync refresh after git fetch completes. That 507ms is wall time where the UI is blocked, versus ~57ms on v0.59.0 for the same refresh without the PR scope.

Reproducible on a fresh git clone https://github.com/jesseduffield/lazygit.git with LOG_LEVEL=info lazygit --debug.

And you're right on the gh-resolved fallback — I re-tested and the single-remote fallback does work correctly on this repo. That part of the issue was wrong, my mistake.

[stefanhaller]

But the second one runs in sync mode and blocks the UI

I think you are getting fooled by the logs here. It does not block the UI. If you can reproduce user-observable behavior where the UI is actually blocked, please let me know; that would be very bad, and I'm sure we would have noticed during development (Jesse, who did most of the work on that PR, is very sensitive to these things). What the log says is that the refresh happens in sync mode relative to the go routine it's running on, but that go routine is itself already a background go routine.

And you're right on the gh-resolved fallback — I re-tested and the single-remote fallback does work correctly on this repo. That part of the issue was wrong, my mistake.

But it's still good that you brought it up, because it does point to misbehavior. In your case it should have prompted you for the base repo, but didn't, and showed no PRs instead. Not good, and I think we should remove the "origin" fallback to improve this.

[Aayush9029]

ty @stefanhaller I can close this issue for now