[Bug]: Background PR sync and settlement send 500–1,100 GitHub GraphQL calls an hour on a ~50-thread server and keep polling threads whose worktree is gone (18,787 failed lookups and 482,099 "settlement skipped" lines in 11 days) #21372

Before submitting

• I searched existing issues and did not find a duplicate. Pull Requests page spends ~170 GraphQL points per refresh and re-lists after every agent turn, exhausting the quota in minutes #19363 is the Pull Requests page (client refresh cost); [Bug]: vcs.refreshStatus waits on GitHub PR lookup; a slow or hung gh keeps "Some requests are slow" toasts coming #16237 is a hung gh; PR fix(server): PR sync stops reading missing pull requests every minute #17800 stops re-reading missing PRs every minute; [Bug]: Partial-clone remote annotations break repository detection and hide linked PRs #12764 is the [blob:none] remote regex. This report is the server's background sync volume as a whole, with a fix we already run.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

1. Run a headless server with ~50 threads, most on branches with an open PR, in a GitHub repository.
2. Count POST https://api.github.com/graphql from the server process for a day (we first metered through a gh shim; since nightly 2761 the server uses its own HTTPS client with the gh auth token value, so we metered the socket).
3. Remove a few threads' worktrees (or let a worktree reaper do it) and watch the journal.

Expected behavior

• One sync tick (10 minutes is fine; configurable) on which all stale PR lookups fall due together and are read in shared GraphQL documents.
• No lookups for provider-native subagent threads whose root is archived or settled, for threads whose directory is not a repository, or for threads whose worktree no longer exists.
• No rateLimit probe when the server is idle.
• Well under GitHub's budget: we target ≤283 calls a day for this server.

Actual behavior

Journal, 2026-10-06 19:10 → 2026-10-17 21:29 (11 days): automatic thread settlement skipped 482,099 lines; thread branch pull request lookup failed 18,787 (GitManager.branchPullRequest.remotes ... (not_a_repository) 13,429, No unknown source control provider is registered 2,458, Failed to spawn Git process 314); pull request sync skipped 1,490; thread pull request update failed 626; PR lookup failed; keeping last known PR state. 331. Most of these are threads whose worktree was removed; the server keeps polling them.

Also: the remote regex (three copies) rejects origin <url> (fetch) [blob:none], so a partial clone resolves to provider unknown, PR badges go blank and merge settlement stops (#12764).

Impact

Major degradation or frequent failure (shares the user's GitHub rate limit with every other tool on the box; PR badges and auto-settlement stopped twice)

Version or commit

0.0.46-nightly.20261004.2657 → 0.0.46-nightly.20261008.2819. Our running build carries the fix below.

Environment

Linux (Ubuntu, kernel 7.0.0-38-generic), compiled @t3code/t3-linux-x64 binary (Node.js v26.8.2 in crash traces), t3 serve --host 127.0.0.1 --port 3773 --base-dir ~/.t3 as a systemd --user service, headless; Tailscale serve in front; clients: macOS desktop app, iOS app, web. 40–50 live threads at a time over 8 Claude Code instances (claudeAgent), 3 Codex instances and ACP providers (Grok CLI, OpenCode with GLM). ~16,900 threads in statev2.sqlite (40.4 GB). Threads are created, woken and stopped by our own tooling over the /ws RPC (orchestration.dispatchCommand), not by a human in the UI.

Running build: 0.0.46-nightly.20261008.2819 with two local server patches (GitHub PR-sync cadence, Grok multi-task wait). Each draft says whether the patch touches the reported area.

Logs or stack traces

thread branch pull request lookup failed ... GitManager.branchPullRequest.remotes ... (not_a_repository)
automatic thread settlement skipped ...
PR lookup failed; keeping last known PR state.

Workaround

We run the fix as fork patches (MattRiddell/t3code PRs #4, #6, #7, #8; four commits, tests included): PR lookup cache 60 s → 10 min; sync and settlement passes on a shared 10-minute tick (entries expire at the tick so they go stale together); finished runs and checkpoints read the cached answer; summary batch window 10 ms → 250 ms; no lookups for subagents of archived/settled roots; branch pass skips a thread whose open PR is known; [blob:none] accepted by the remote regex. Result on our server: 1,414 → 507 → ~283 calls a day. Happy to open these against main if wanted.