fix(server): stop re-fetching PRs for settled/merged worktrees by patroza · Pull Request #362 · patroza/t3code

patroza · 2026-08-06T10:00:50Z

Summary

Stops expensive hosting-provider PR lookups (gh pr list, etc.) from running forever on worktrees that are done — the main source of t3vm PR lookup failed; keeping last known PR state spam when Discord keeps bridges warm for old merged threads.

Behavior

Terminal PR freeze — once remote status observes a merged or closed PR for a worktree head (under the current invalidate epoch), further polls serve last-known state and do not re-list PRs.
Durable settle freeze — thread.settled with a worktree path registers interest; while any settled thread owns that path, PR list is skipped. thread.unsettled drops interest so the next poll can hit the live path again.
Resume — explicit invalidateStatus (user refresh / git actions) bumps the PR lookup epoch and re-opens terminal freeze; unsettle clears settle interest.

Local ahead/behind git status continues to refresh; only the hosting-provider PR association is frozen.

Why not client-only?

Web/desktop already hide settled rows, but Discord rehydrates idle links and holds full-mode VCS pollers. Server-side freeze stops gh regardless of who is subscribed.

Test plan

vp test run apps/server/src/git/PrLookupFreeze.test.ts
vp test run apps/server/src/git/GitManager.test.ts (terminal freeze + settle freeze cases)
vp test run apps/server/src/orchestration/Layers/ProjectionPipeline.test.ts
After deploy: confirm t3vm no longer WARN-spams lookupStatusPr for long-merged feature branches on idle Discord bridges
Unsettle a settled worktree thread and confirm PR badge still refreshes on the next poll / status refresh

Periodic VCS polls (Discord bridges + sidebar list mode) kept calling gh for every worktree after PRs merged, producing SourceControlProviderError noise and rate-limit pressure. Freeze hosting-provider PR lookup once we observe a merged/closed PR for a head, and while durable thread settle owns the worktree; unsettle drops settle interest so the next poll can resume.

@patroza

…373) PR badges stopped appearing in sidebar v2 for **active** threads, while settled rows kept theirs. Root-caused on the running server, fix verified against the exact failing invocation. ## What was happening The server's VCS shell-outs resolve `gh` through each repo's `.tools/bin` — the agent policy shim installed by `scripts/install-git-hooks.mjs`. Caught live off the server process: ``` CMD=node /var/lib/t3/deploy/t3code/scripts/agent-gh.mjs pr list --head release-cut-mako-easylife \ --state all --limit 20 --json number,title,url,... ``` That shim resolves the binary to delegate to via `findRealGh`, which preferred `$T3_GITHUB_REAL_GH` above everything else. **That variable names the unauthenticated `gh`** — the binary the GitHub App wrapper execs *after* minting an installation token. The host exports it (see the server start script: _"still export REAL_GH / token paths so children that reorder PATH cannot lose minting config"_) as configuration for the wrapper, not as an authenticated entry point. So the shim skipped minting entirely and ran raw `gh`: ``` $ env -i $(server env) .tools/bin/gh pr list --head release-cut-mako-easylife --state all ... To get started with GitHub CLI, please run: gh auth login exit=4 ``` Exit 4 → `SourceControlProviderError` → the warning that has been filling the journal every 45s: ``` WARN: PR lookup failed; keeping last known PR state. operation: lookupStatusPr errorTag: SourceControlProviderError branch: release-cut-mako-easylife ``` ## Why settled rows still showed badges That asymmetry is the tell. Settled worktrees take the durable settle freeze added in #362, which returns `resolveLastKnownPr(...)` **without calling the provider at all**. A frozen row can't fail a lookup it never makes. Every active row goes down the live path, hits the auth failure, and falls back to a last-known value that is empty — so the card renders with no badge. Introduced by `2ef070919` (2026-08-02, "enforce repository-owned agent ship gates"), which added the `T3_GITHUB_REAL_GH` branch to `findRealGh`. ## The fix Resolution order becomes: 1. `AGENT_GH_REAL` — this shim's own re-entry override, unchanged. 2. **PATH** — where the App-aware `gh` lives. 3. `T3_GITHUB_REAL_GH` — last resort only, so hosts without a wrapper still work. ## Verification The same command that returned exit 4, under the server's exact environment, after the change: ``` $ .tools/bin/gh pr list --head sync/upstream-48aa875c0 --state all --limit 5 --json number,state [{"number":372,"state":"MERGED"}] ``` Regression test added to `scripts/agent-pre-push.test.mjs` pinning all three tiers of the order; it fails on the pre-fix implementation and passes after. Full file: 26 tests pass. The deploy checkout was patched only to prove the fix live and has been restored to its released state, so the fleet stays consistent with its deployed SHA until this lands. Co-authored by [@patroza](https://github.com/patroza) opened by [Patrick Roza](https://discord.com/users/95218063095377920) in chat thread **Discord** · [Discord](https://discord.com/channels/1083767712431480922/1534783738322485399/1534783738322485399) · [T3](https://t3vm/?thread=584a9ad3-243e-4308-8a13-49acdd758b17) Co-authored-by: omegent-app[bot] <306514130+omegent-app[bot]@users.noreply.github.com> Co-authored-by: Patrick Roza <42661+patroza@users.noreply.github.com>

patroza · 2026-08-06T10:00:50Z

Summary

Stops expensive hosting-provider PR lookups (gh pr list, etc.) from running forever on worktrees that are done — the main source of t3vm PR lookup failed; keeping last known PR state spam when Discord keeps bridges warm for old merged threads.

Behavior

Terminal PR freeze — once remote status observes a merged or closed PR for a worktree head (under the current invalidate epoch), further polls serve last-known state and do not re-list PRs.
Durable settle freeze — thread.settled with a worktree path registers interest; while any settled thread owns that path, PR list is skipped. thread.unsettled drops interest so the next poll can hit the live path again.
Resume — explicit invalidateStatus (user refresh / git actions) bumps the PR lookup epoch and re-opens terminal freeze; unsettle clears settle interest.

Local ahead/behind git status continues to refresh; only the hosting-provider PR association is frozen.

Why not client-only?

Web/desktop already hide settled rows, but Discord rehydrates idle links and holds full-mode VCS pollers. Server-side freeze stops gh regardless of who is subscribed.

Test plan

vp test run apps/server/src/git/PrLookupFreeze.test.ts
vp test run apps/server/src/git/GitManager.test.ts (terminal freeze + settle freeze cases)
vp test run apps/server/src/orchestration/Layers/ProjectionPipeline.test.ts
After deploy: confirm t3vm no longer WARN-spams lookupStatusPr for long-merged feature branches on idle Discord bridges
Unsettle a settled worktree thread and confirm PR badge still refreshes on the next poll / status refresh

Periodic VCS polls (Discord bridges + sidebar list mode) kept calling gh for every worktree after PRs merged, producing SourceControlProviderError noise and rate-limit pressure. Freeze hosting-provider PR lookup once we observe a merged/closed PR for a head, and while durable thread settle owns the worktree; unsettle drops settle interest so the next poll can resume.

@patroza

…373) PR badges stopped appearing in sidebar v2 for **active** threads, while settled rows kept theirs. Root-caused on the running server, fix verified against the exact failing invocation. ## What was happening The server's VCS shell-outs resolve `gh` through each repo's `.tools/bin` — the agent policy shim installed by `scripts/install-git-hooks.mjs`. Caught live off the server process: ``` CMD=node /var/lib/t3/deploy/t3code/scripts/agent-gh.mjs pr list --head release-cut-mako-easylife \ --state all --limit 20 --json number,title,url,... ``` That shim resolves the binary to delegate to via `findRealGh`, which preferred `$T3_GITHUB_REAL_GH` above everything else. **That variable names the unauthenticated `gh`** — the binary the GitHub App wrapper execs *after* minting an installation token. The host exports it (see the server start script: _"still export REAL_GH / token paths so children that reorder PATH cannot lose minting config"_) as configuration for the wrapper, not as an authenticated entry point. So the shim skipped minting entirely and ran raw `gh`: ``` $ env -i $(server env) .tools/bin/gh pr list --head release-cut-mako-easylife --state all ... To get started with GitHub CLI, please run: gh auth login exit=4 ``` Exit 4 → `SourceControlProviderError` → the warning that has been filling the journal every 45s: ``` WARN: PR lookup failed; keeping last known PR state. operation: lookupStatusPr errorTag: SourceControlProviderError branch: release-cut-mako-easylife ``` ## Why settled rows still showed badges That asymmetry is the tell. Settled worktrees take the durable settle freeze added in #362, which returns `resolveLastKnownPr(...)` **without calling the provider at all**. A frozen row can't fail a lookup it never makes. Every active row goes down the live path, hits the auth failure, and falls back to a last-known value that is empty — so the card renders with no badge. Introduced by `2ef070919` (2026-08-02, "enforce repository-owned agent ship gates"), which added the `T3_GITHUB_REAL_GH` branch to `findRealGh`. ## The fix Resolution order becomes: 1. `AGENT_GH_REAL` — this shim's own re-entry override, unchanged. 2. **PATH** — where the App-aware `gh` lives. 3. `T3_GITHUB_REAL_GH` — last resort only, so hosts without a wrapper still work. ## Verification The same command that returned exit 4, under the server's exact environment, after the change: ``` $ .tools/bin/gh pr list --head sync/upstream-48aa875c0 --state all --limit 5 --json number,state [{"number":372,"state":"MERGED"}] ``` Regression test added to `scripts/agent-pre-push.test.mjs` pinning all three tiers of the order; it fails on the pre-fix implementation and passes after. Full file: 26 tests pass. The deploy checkout was patched only to prove the fix live and has been restored to its released state, so the fleet stays consistent with its deployed SHA until this lands. Co-authored by [@patroza](https://github.com/patroza) opened by [Patrick Roza](https://discord.com/users/95218063095377920) in chat thread **Discord** · [Discord](https://discord.com/channels/1083767712431480922/1534783738322485399/1534783738322485399) · [T3](https://t3vm/?thread=584a9ad3-243e-4308-8a13-49acdd758b17) Co-authored-by: omegent-app[bot] <306514130+omegent-app[bot]@users.noreply.github.com> Co-authored-by: Patrick Roza <42661+patroza@users.noreply.github.com>

patroza · 2026-08-06T10:00:50Z

Summary

Stops expensive hosting-provider PR lookups (gh pr list, etc.) from running forever on worktrees that are done — the main source of t3vm PR lookup failed; keeping last known PR state spam when Discord keeps bridges warm for old merged threads.

Behavior

Terminal PR freeze — once remote status observes a merged or closed PR for a worktree head (under the current invalidate epoch), further polls serve last-known state and do not re-list PRs.
Durable settle freeze — thread.settled with a worktree path registers interest; while any settled thread owns that path, PR list is skipped. thread.unsettled drops interest so the next poll can hit the live path again.
Resume — explicit invalidateStatus (user refresh / git actions) bumps the PR lookup epoch and re-opens terminal freeze; unsettle clears settle interest.

Local ahead/behind git status continues to refresh; only the hosting-provider PR association is frozen.

Why not client-only?

Web/desktop already hide settled rows, but Discord rehydrates idle links and holds full-mode VCS pollers. Server-side freeze stops gh regardless of who is subscribed.

Test plan

vp test run apps/server/src/git/PrLookupFreeze.test.ts
vp test run apps/server/src/git/GitManager.test.ts (terminal freeze + settle freeze cases)
vp test run apps/server/src/orchestration/Layers/ProjectionPipeline.test.ts
After deploy: confirm t3vm no longer WARN-spams lookupStatusPr for long-merged feature branches on idle Discord bridges
Unsettle a settled worktree thread and confirm PR badge still refreshes on the next poll / status refresh

Periodic VCS polls (Discord bridges + sidebar list mode) kept calling gh for every worktree after PRs merged, producing SourceControlProviderError noise and rate-limit pressure. Freeze hosting-provider PR lookup once we observe a merged/closed PR for a head, and while durable thread settle owns the worktree; unsettle drops settle interest so the next poll can resume.

@patroza

…373) PR badges stopped appearing in sidebar v2 for **active** threads, while settled rows kept theirs. Root-caused on the running server, fix verified against the exact failing invocation. ## What was happening The server's VCS shell-outs resolve `gh` through each repo's `.tools/bin` — the agent policy shim installed by `scripts/install-git-hooks.mjs`. Caught live off the server process: ``` CMD=node /var/lib/t3/deploy/t3code/scripts/agent-gh.mjs pr list --head release-cut-mako-easylife \ --state all --limit 20 --json number,title,url,... ``` That shim resolves the binary to delegate to via `findRealGh`, which preferred `$T3_GITHUB_REAL_GH` above everything else. **That variable names the unauthenticated `gh`** — the binary the GitHub App wrapper execs *after* minting an installation token. The host exports it (see the server start script: _"still export REAL_GH / token paths so children that reorder PATH cannot lose minting config"_) as configuration for the wrapper, not as an authenticated entry point. So the shim skipped minting entirely and ran raw `gh`: ``` $ env -i $(server env) .tools/bin/gh pr list --head release-cut-mako-easylife --state all ... To get started with GitHub CLI, please run: gh auth login exit=4 ``` Exit 4 → `SourceControlProviderError` → the warning that has been filling the journal every 45s: ``` WARN: PR lookup failed; keeping last known PR state. operation: lookupStatusPr errorTag: SourceControlProviderError branch: release-cut-mako-easylife ``` ## Why settled rows still showed badges That asymmetry is the tell. Settled worktrees take the durable settle freeze added in #362, which returns `resolveLastKnownPr(...)` **without calling the provider at all**. A frozen row can't fail a lookup it never makes. Every active row goes down the live path, hits the auth failure, and falls back to a last-known value that is empty — so the card renders with no badge. Introduced by `2ef070919` (2026-08-02, "enforce repository-owned agent ship gates"), which added the `T3_GITHUB_REAL_GH` branch to `findRealGh`. ## The fix Resolution order becomes: 1. `AGENT_GH_REAL` — this shim's own re-entry override, unchanged. 2. **PATH** — where the App-aware `gh` lives. 3. `T3_GITHUB_REAL_GH` — last resort only, so hosts without a wrapper still work. ## Verification The same command that returned exit 4, under the server's exact environment, after the change: ``` $ .tools/bin/gh pr list --head sync/upstream-48aa875c0 --state all --limit 5 --json number,state [{"number":372,"state":"MERGED"}] ``` Regression test added to `scripts/agent-pre-push.test.mjs` pinning all three tiers of the order; it fails on the pre-fix implementation and passes after. Full file: 26 tests pass. The deploy checkout was patched only to prove the fix live and has been restored to its released state, so the fleet stays consistent with its deployed SHA until this lands. Co-authored by [@patroza](https://github.com/patroza) opened by [Patrick Roza](https://discord.com/users/95218063095377920) in chat thread **Discord** · [Discord](https://discord.com/channels/1083767712431480922/1534783738322485399/1534783738322485399) · [T3](https://t3vm/?thread=584a9ad3-243e-4308-8a13-49acdd758b17) Co-authored-by: omegent-app[bot] <306514130+omegent-app[bot]@users.noreply.github.com> Co-authored-by: Patrick Roza <42661+patroza@users.noreply.github.com>

patroza · 2026-08-06T10:00:50Z

Summary

Stops expensive hosting-provider PR lookups (gh pr list, etc.) from running forever on worktrees that are done — the main source of t3vm PR lookup failed; keeping last known PR state spam when Discord keeps bridges warm for old merged threads.

Behavior

Terminal PR freeze — once remote status observes a merged or closed PR for a worktree head (under the current invalidate epoch), further polls serve last-known state and do not re-list PRs.
Durable settle freeze — thread.settled with a worktree path registers interest; while any settled thread owns that path, PR list is skipped. thread.unsettled drops interest so the next poll can hit the live path again.
Resume — explicit invalidateStatus (user refresh / git actions) bumps the PR lookup epoch and re-opens terminal freeze; unsettle clears settle interest.

Local ahead/behind git status continues to refresh; only the hosting-provider PR association is frozen.

Why not client-only?

Web/desktop already hide settled rows, but Discord rehydrates idle links and holds full-mode VCS pollers. Server-side freeze stops gh regardless of who is subscribed.

Test plan

vp test run apps/server/src/git/PrLookupFreeze.test.ts
vp test run apps/server/src/git/GitManager.test.ts (terminal freeze + settle freeze cases)
vp test run apps/server/src/orchestration/Layers/ProjectionPipeline.test.ts
After deploy: confirm t3vm no longer WARN-spams lookupStatusPr for long-merged feature branches on idle Discord bridges
Unsettle a settled worktree thread and confirm PR badge still refreshes on the next poll / status refresh

Periodic VCS polls (Discord bridges + sidebar list mode) kept calling gh for every worktree after PRs merged, producing SourceControlProviderError noise and rate-limit pressure. Freeze hosting-provider PR lookup once we observe a merged/closed PR for a head, and while durable thread settle owns the worktree; unsettle drops settle interest so the next poll can resume.

@patroza

…373) PR badges stopped appearing in sidebar v2 for **active** threads, while settled rows kept theirs. Root-caused on the running server, fix verified against the exact failing invocation. ## What was happening The server's VCS shell-outs resolve `gh` through each repo's `.tools/bin` — the agent policy shim installed by `scripts/install-git-hooks.mjs`. Caught live off the server process: ``` CMD=node /var/lib/t3/deploy/t3code/scripts/agent-gh.mjs pr list --head release-cut-mako-easylife \ --state all --limit 20 --json number,title,url,... ``` That shim resolves the binary to delegate to via `findRealGh`, which preferred `$T3_GITHUB_REAL_GH` above everything else. **That variable names the unauthenticated `gh`** — the binary the GitHub App wrapper execs *after* minting an installation token. The host exports it (see the server start script: _"still export REAL_GH / token paths so children that reorder PATH cannot lose minting config"_) as configuration for the wrapper, not as an authenticated entry point. So the shim skipped minting entirely and ran raw `gh`: ``` $ env -i $(server env) .tools/bin/gh pr list --head release-cut-mako-easylife --state all ... To get started with GitHub CLI, please run: gh auth login exit=4 ``` Exit 4 → `SourceControlProviderError` → the warning that has been filling the journal every 45s: ``` WARN: PR lookup failed; keeping last known PR state. operation: lookupStatusPr errorTag: SourceControlProviderError branch: release-cut-mako-easylife ``` ## Why settled rows still showed badges That asymmetry is the tell. Settled worktrees take the durable settle freeze added in #362, which returns `resolveLastKnownPr(...)` **without calling the provider at all**. A frozen row can't fail a lookup it never makes. Every active row goes down the live path, hits the auth failure, and falls back to a last-known value that is empty — so the card renders with no badge. Introduced by `2ef070919` (2026-08-02, "enforce repository-owned agent ship gates"), which added the `T3_GITHUB_REAL_GH` branch to `findRealGh`. ## The fix Resolution order becomes: 1. `AGENT_GH_REAL` — this shim's own re-entry override, unchanged. 2. **PATH** — where the App-aware `gh` lives. 3. `T3_GITHUB_REAL_GH` — last resort only, so hosts without a wrapper still work. ## Verification The same command that returned exit 4, under the server's exact environment, after the change: ``` $ .tools/bin/gh pr list --head sync/upstream-48aa875c0 --state all --limit 5 --json number,state [{"number":372,"state":"MERGED"}] ``` Regression test added to `scripts/agent-pre-push.test.mjs` pinning all three tiers of the order; it fails on the pre-fix implementation and passes after. Full file: 26 tests pass. The deploy checkout was patched only to prove the fix live and has been restored to its released state, so the fleet stays consistent with its deployed SHA until this lands. Co-authored by [@patroza](https://github.com/patroza) opened by [Patrick Roza](https://discord.com/users/95218063095377920) in chat thread **Discord** · [Discord](https://discord.com/channels/1083767712431480922/1534783738322485399/1534783738322485399) · [T3](https://t3vm/?thread=584a9ad3-243e-4308-8a13-49acdd758b17) Co-authored-by: omegent-app[bot] <306514130+omegent-app[bot]@users.noreply.github.com> Co-authored-by: Patrick Roza <42661+patroza@users.noreply.github.com>

patroza · 2026-08-06T10:00:50Z

Summary

Stops expensive hosting-provider PR lookups (gh pr list, etc.) from running forever on worktrees that are done — the main source of t3vm PR lookup failed; keeping last known PR state spam when Discord keeps bridges warm for old merged threads.

Behavior

Terminal PR freeze — once remote status observes a merged or closed PR for a worktree head (under the current invalidate epoch), further polls serve last-known state and do not re-list PRs.
Durable settle freeze — thread.settled with a worktree path registers interest; while any settled thread owns that path, PR list is skipped. thread.unsettled drops interest so the next poll can hit the live path again.
Resume — explicit invalidateStatus (user refresh / git actions) bumps the PR lookup epoch and re-opens terminal freeze; unsettle clears settle interest.

Local ahead/behind git status continues to refresh; only the hosting-provider PR association is frozen.

Why not client-only?

Web/desktop already hide settled rows, but Discord rehydrates idle links and holds full-mode VCS pollers. Server-side freeze stops gh regardless of who is subscribed.

Test plan

vp test run apps/server/src/git/PrLookupFreeze.test.ts
vp test run apps/server/src/git/GitManager.test.ts (terminal freeze + settle freeze cases)
vp test run apps/server/src/orchestration/Layers/ProjectionPipeline.test.ts
After deploy: confirm t3vm no longer WARN-spams lookupStatusPr for long-merged feature branches on idle Discord bridges
Unsettle a settled worktree thread and confirm PR badge still refreshes on the next poll / status refresh

Periodic VCS polls (Discord bridges + sidebar list mode) kept calling gh for every worktree after PRs merged, producing SourceControlProviderError noise and rate-limit pressure. Freeze hosting-provider PR lookup once we observe a merged/closed PR for a head, and while durable thread settle owns the worktree; unsettle drops settle interest so the next poll can resume.

@patroza

…373) PR badges stopped appearing in sidebar v2 for **active** threads, while settled rows kept theirs. Root-caused on the running server, fix verified against the exact failing invocation. ## What was happening The server's VCS shell-outs resolve `gh` through each repo's `.tools/bin` — the agent policy shim installed by `scripts/install-git-hooks.mjs`. Caught live off the server process: ``` CMD=node /var/lib/t3/deploy/t3code/scripts/agent-gh.mjs pr list --head release-cut-mako-easylife \ --state all --limit 20 --json number,title,url,... ``` That shim resolves the binary to delegate to via `findRealGh`, which preferred `$T3_GITHUB_REAL_GH` above everything else. **That variable names the unauthenticated `gh`** — the binary the GitHub App wrapper execs *after* minting an installation token. The host exports it (see the server start script: _"still export REAL_GH / token paths so children that reorder PATH cannot lose minting config"_) as configuration for the wrapper, not as an authenticated entry point. So the shim skipped minting entirely and ran raw `gh`: ``` $ env -i $(server env) .tools/bin/gh pr list --head release-cut-mako-easylife --state all ... To get started with GitHub CLI, please run: gh auth login exit=4 ``` Exit 4 → `SourceControlProviderError` → the warning that has been filling the journal every 45s: ``` WARN: PR lookup failed; keeping last known PR state. operation: lookupStatusPr errorTag: SourceControlProviderError branch: release-cut-mako-easylife ``` ## Why settled rows still showed badges That asymmetry is the tell. Settled worktrees take the durable settle freeze added in #362, which returns `resolveLastKnownPr(...)` **without calling the provider at all**. A frozen row can't fail a lookup it never makes. Every active row goes down the live path, hits the auth failure, and falls back to a last-known value that is empty — so the card renders with no badge. Introduced by `2ef070919` (2026-08-02, "enforce repository-owned agent ship gates"), which added the `T3_GITHUB_REAL_GH` branch to `findRealGh`. ## The fix Resolution order becomes: 1. `AGENT_GH_REAL` — this shim's own re-entry override, unchanged. 2. **PATH** — where the App-aware `gh` lives. 3. `T3_GITHUB_REAL_GH` — last resort only, so hosts without a wrapper still work. ## Verification The same command that returned exit 4, under the server's exact environment, after the change: ``` $ .tools/bin/gh pr list --head sync/upstream-48aa875c0 --state all --limit 5 --json number,state [{"number":372,"state":"MERGED"}] ``` Regression test added to `scripts/agent-pre-push.test.mjs` pinning all three tiers of the order; it fails on the pre-fix implementation and passes after. Full file: 26 tests pass. The deploy checkout was patched only to prove the fix live and has been restored to its released state, so the fleet stays consistent with its deployed SHA until this lands. Co-authored by [@patroza](https://github.com/patroza) opened by [Patrick Roza](https://discord.com/users/95218063095377920) in chat thread **Discord** · [Discord](https://discord.com/channels/1083767712431480922/1534783738322485399/1534783738322485399) · [T3](https://t3vm/?thread=584a9ad3-243e-4308-8a13-49acdd758b17) Co-authored-by: omegent-app[bot] <306514130+omegent-app[bot]@users.noreply.github.com> Co-authored-by: Patrick Roza <42661+patroza@users.noreply.github.com>

patroza · 2026-08-06T10:00:50Z

Summary

Stops expensive hosting-provider PR lookups (gh pr list, etc.) from running forever on worktrees that are done — the main source of t3vm PR lookup failed; keeping last known PR state spam when Discord keeps bridges warm for old merged threads.

Behavior

Terminal PR freeze — once remote status observes a merged or closed PR for a worktree head (under the current invalidate epoch), further polls serve last-known state and do not re-list PRs.
Durable settle freeze — thread.settled with a worktree path registers interest; while any settled thread owns that path, PR list is skipped. thread.unsettled drops interest so the next poll can hit the live path again.
Resume — explicit invalidateStatus (user refresh / git actions) bumps the PR lookup epoch and re-opens terminal freeze; unsettle clears settle interest.

Local ahead/behind git status continues to refresh; only the hosting-provider PR association is frozen.

Why not client-only?

Web/desktop already hide settled rows, but Discord rehydrates idle links and holds full-mode VCS pollers. Server-side freeze stops gh regardless of who is subscribed.

Test plan

vp test run apps/server/src/git/PrLookupFreeze.test.ts
vp test run apps/server/src/git/GitManager.test.ts (terminal freeze + settle freeze cases)
vp test run apps/server/src/orchestration/Layers/ProjectionPipeline.test.ts
After deploy: confirm t3vm no longer WARN-spams lookupStatusPr for long-merged feature branches on idle Discord bridges
Unsettle a settled worktree thread and confirm PR badge still refreshes on the next poll / status refresh

Periodic VCS polls (Discord bridges + sidebar list mode) kept calling gh for every worktree after PRs merged, producing SourceControlProviderError noise and rate-limit pressure. Freeze hosting-provider PR lookup once we observe a merged/closed PR for a head, and while durable thread settle owns the worktree; unsettle drops settle interest so the next poll can resume.

@patroza

…373) PR badges stopped appearing in sidebar v2 for **active** threads, while settled rows kept theirs. Root-caused on the running server, fix verified against the exact failing invocation. ## What was happening The server's VCS shell-outs resolve `gh` through each repo's `.tools/bin` — the agent policy shim installed by `scripts/install-git-hooks.mjs`. Caught live off the server process: ``` CMD=node /var/lib/t3/deploy/t3code/scripts/agent-gh.mjs pr list --head release-cut-mako-easylife \ --state all --limit 20 --json number,title,url,... ``` That shim resolves the binary to delegate to via `findRealGh`, which preferred `$T3_GITHUB_REAL_GH` above everything else. **That variable names the unauthenticated `gh`** — the binary the GitHub App wrapper execs *after* minting an installation token. The host exports it (see the server start script: _"still export REAL_GH / token paths so children that reorder PATH cannot lose minting config"_) as configuration for the wrapper, not as an authenticated entry point. So the shim skipped minting entirely and ran raw `gh`: ``` $ env -i $(server env) .tools/bin/gh pr list --head release-cut-mako-easylife --state all ... To get started with GitHub CLI, please run: gh auth login exit=4 ``` Exit 4 → `SourceControlProviderError` → the warning that has been filling the journal every 45s: ``` WARN: PR lookup failed; keeping last known PR state. operation: lookupStatusPr errorTag: SourceControlProviderError branch: release-cut-mako-easylife ``` ## Why settled rows still showed badges That asymmetry is the tell. Settled worktrees take the durable settle freeze added in #362, which returns `resolveLastKnownPr(...)` **without calling the provider at all**. A frozen row can't fail a lookup it never makes. Every active row goes down the live path, hits the auth failure, and falls back to a last-known value that is empty — so the card renders with no badge. Introduced by `2ef070919` (2026-08-02, "enforce repository-owned agent ship gates"), which added the `T3_GITHUB_REAL_GH` branch to `findRealGh`. ## The fix Resolution order becomes: 1. `AGENT_GH_REAL` — this shim's own re-entry override, unchanged. 2. **PATH** — where the App-aware `gh` lives. 3. `T3_GITHUB_REAL_GH` — last resort only, so hosts without a wrapper still work. ## Verification The same command that returned exit 4, under the server's exact environment, after the change: ``` $ .tools/bin/gh pr list --head sync/upstream-48aa875c0 --state all --limit 5 --json number,state [{"number":372,"state":"MERGED"}] ``` Regression test added to `scripts/agent-pre-push.test.mjs` pinning all three tiers of the order; it fails on the pre-fix implementation and passes after. Full file: 26 tests pass. The deploy checkout was patched only to prove the fix live and has been restored to its released state, so the fleet stays consistent with its deployed SHA until this lands. Co-authored by [@patroza](https://github.com/patroza) opened by [Patrick Roza](https://discord.com/users/95218063095377920) in chat thread **Discord** · [Discord](https://discord.com/channels/1083767712431480922/1534783738322485399/1534783738322485399) · [T3](https://t3vm/?thread=584a9ad3-243e-4308-8a13-49acdd758b17) Co-authored-by: omegent-app[bot] <306514130+omegent-app[bot]@users.noreply.github.com> Co-authored-by: Patrick Roza <42661+patroza@users.noreply.github.com>

patroza · 2026-08-06T10:00:50Z

Summary

Stops expensive hosting-provider PR lookups (gh pr list, etc.) from running forever on worktrees that are done — the main source of t3vm PR lookup failed; keeping last known PR state spam when Discord keeps bridges warm for old merged threads.

Behavior

Terminal PR freeze — once remote status observes a merged or closed PR for a worktree head (under the current invalidate epoch), further polls serve last-known state and do not re-list PRs.
Durable settle freeze — thread.settled with a worktree path registers interest; while any settled thread owns that path, PR list is skipped. thread.unsettled drops interest so the next poll can hit the live path again.
Resume — explicit invalidateStatus (user refresh / git actions) bumps the PR lookup epoch and re-opens terminal freeze; unsettle clears settle interest.

Local ahead/behind git status continues to refresh; only the hosting-provider PR association is frozen.

Why not client-only?

Web/desktop already hide settled rows, but Discord rehydrates idle links and holds full-mode VCS pollers. Server-side freeze stops gh regardless of who is subscribed.

Test plan

vp test run apps/server/src/git/PrLookupFreeze.test.ts
vp test run apps/server/src/git/GitManager.test.ts (terminal freeze + settle freeze cases)
vp test run apps/server/src/orchestration/Layers/ProjectionPipeline.test.ts
After deploy: confirm t3vm no longer WARN-spams lookupStatusPr for long-merged feature branches on idle Discord bridges
Unsettle a settled worktree thread and confirm PR badge still refreshes on the next poll / status refresh

Periodic VCS polls (Discord bridges + sidebar list mode) kept calling gh for every worktree after PRs merged, producing SourceControlProviderError noise and rate-limit pressure. Freeze hosting-provider PR lookup once we observe a merged/closed PR for a head, and while durable thread settle owns the worktree; unsettle drops settle interest so the next poll can resume.

@patroza

…373) PR badges stopped appearing in sidebar v2 for **active** threads, while settled rows kept theirs. Root-caused on the running server, fix verified against the exact failing invocation. ## What was happening The server's VCS shell-outs resolve `gh` through each repo's `.tools/bin` — the agent policy shim installed by `scripts/install-git-hooks.mjs`. Caught live off the server process: ``` CMD=node /var/lib/t3/deploy/t3code/scripts/agent-gh.mjs pr list --head release-cut-mako-easylife \ --state all --limit 20 --json number,title,url,... ``` That shim resolves the binary to delegate to via `findRealGh`, which preferred `$T3_GITHUB_REAL_GH` above everything else. **That variable names the unauthenticated `gh`** — the binary the GitHub App wrapper execs *after* minting an installation token. The host exports it (see the server start script: _"still export REAL_GH / token paths so children that reorder PATH cannot lose minting config"_) as configuration for the wrapper, not as an authenticated entry point. So the shim skipped minting entirely and ran raw `gh`: ``` $ env -i $(server env) .tools/bin/gh pr list --head release-cut-mako-easylife --state all ... To get started with GitHub CLI, please run: gh auth login exit=4 ``` Exit 4 → `SourceControlProviderError` → the warning that has been filling the journal every 45s: ``` WARN: PR lookup failed; keeping last known PR state. operation: lookupStatusPr errorTag: SourceControlProviderError branch: release-cut-mako-easylife ``` ## Why settled rows still showed badges That asymmetry is the tell. Settled worktrees take the durable settle freeze added in #362, which returns `resolveLastKnownPr(...)` **without calling the provider at all**. A frozen row can't fail a lookup it never makes. Every active row goes down the live path, hits the auth failure, and falls back to a last-known value that is empty — so the card renders with no badge. Introduced by `2ef070919` (2026-08-02, "enforce repository-owned agent ship gates"), which added the `T3_GITHUB_REAL_GH` branch to `findRealGh`. ## The fix Resolution order becomes: 1. `AGENT_GH_REAL` — this shim's own re-entry override, unchanged. 2. **PATH** — where the App-aware `gh` lives. 3. `T3_GITHUB_REAL_GH` — last resort only, so hosts without a wrapper still work. ## Verification The same command that returned exit 4, under the server's exact environment, after the change: ``` $ .tools/bin/gh pr list --head sync/upstream-48aa875c0 --state all --limit 5 --json number,state [{"number":372,"state":"MERGED"}] ``` Regression test added to `scripts/agent-pre-push.test.mjs` pinning all three tiers of the order; it fails on the pre-fix implementation and passes after. Full file: 26 tests pass. The deploy checkout was patched only to prove the fix live and has been restored to its released state, so the fleet stays consistent with its deployed SHA until this lands. Co-authored by [@patroza](https://github.com/patroza) opened by [Patrick Roza](https://discord.com/users/95218063095377920) in chat thread **Discord** · [Discord](https://discord.com/channels/1083767712431480922/1534783738322485399/1534783738322485399) · [T3](https://t3vm/?thread=584a9ad3-243e-4308-8a13-49acdd758b17) Co-authored-by: omegent-app[bot] <306514130+omegent-app[bot]@users.noreply.github.com> Co-authored-by: Patrick Roza <42661+patroza@users.noreply.github.com>

patroza · 2026-08-06T10:00:50Z

Summary

Stops expensive hosting-provider PR lookups (gh pr list, etc.) from running forever on worktrees that are done — the main source of t3vm PR lookup failed; keeping last known PR state spam when Discord keeps bridges warm for old merged threads.

Behavior

Terminal PR freeze — once remote status observes a merged or closed PR for a worktree head (under the current invalidate epoch), further polls serve last-known state and do not re-list PRs.
Durable settle freeze — thread.settled with a worktree path registers interest; while any settled thread owns that path, PR list is skipped. thread.unsettled drops interest so the next poll can hit the live path again.
Resume — explicit invalidateStatus (user refresh / git actions) bumps the PR lookup epoch and re-opens terminal freeze; unsettle clears settle interest.

Local ahead/behind git status continues to refresh; only the hosting-provider PR association is frozen.

Why not client-only?

Web/desktop already hide settled rows, but Discord rehydrates idle links and holds full-mode VCS pollers. Server-side freeze stops gh regardless of who is subscribed.

Test plan

vp test run apps/server/src/git/PrLookupFreeze.test.ts
vp test run apps/server/src/git/GitManager.test.ts (terminal freeze + settle freeze cases)
vp test run apps/server/src/orchestration/Layers/ProjectionPipeline.test.ts
After deploy: confirm t3vm no longer WARN-spams lookupStatusPr for long-merged feature branches on idle Discord bridges
Unsettle a settled worktree thread and confirm PR badge still refreshes on the next poll / status refresh

Periodic VCS polls (Discord bridges + sidebar list mode) kept calling gh for every worktree after PRs merged, producing SourceControlProviderError noise and rate-limit pressure. Freeze hosting-provider PR lookup once we observe a merged/closed PR for a head, and while durable thread settle owns the worktree; unsettle drops settle interest so the next poll can resume.

@patroza

…373) PR badges stopped appearing in sidebar v2 for **active** threads, while settled rows kept theirs. Root-caused on the running server, fix verified against the exact failing invocation. ## What was happening The server's VCS shell-outs resolve `gh` through each repo's `.tools/bin` — the agent policy shim installed by `scripts/install-git-hooks.mjs`. Caught live off the server process: ``` CMD=node /var/lib/t3/deploy/t3code/scripts/agent-gh.mjs pr list --head release-cut-mako-easylife \ --state all --limit 20 --json number,title,url,... ``` That shim resolves the binary to delegate to via `findRealGh`, which preferred `$T3_GITHUB_REAL_GH` above everything else. **That variable names the unauthenticated `gh`** — the binary the GitHub App wrapper execs *after* minting an installation token. The host exports it (see the server start script: _"still export REAL_GH / token paths so children that reorder PATH cannot lose minting config"_) as configuration for the wrapper, not as an authenticated entry point. So the shim skipped minting entirely and ran raw `gh`: ``` $ env -i $(server env) .tools/bin/gh pr list --head release-cut-mako-easylife --state all ... To get started with GitHub CLI, please run: gh auth login exit=4 ``` Exit 4 → `SourceControlProviderError` → the warning that has been filling the journal every 45s: ``` WARN: PR lookup failed; keeping last known PR state. operation: lookupStatusPr errorTag: SourceControlProviderError branch: release-cut-mako-easylife ``` ## Why settled rows still showed badges That asymmetry is the tell. Settled worktrees take the durable settle freeze added in #362, which returns `resolveLastKnownPr(...)` **without calling the provider at all**. A frozen row can't fail a lookup it never makes. Every active row goes down the live path, hits the auth failure, and falls back to a last-known value that is empty — so the card renders with no badge. Introduced by `2ef070919` (2026-08-02, "enforce repository-owned agent ship gates"), which added the `T3_GITHUB_REAL_GH` branch to `findRealGh`. ## The fix Resolution order becomes: 1. `AGENT_GH_REAL` — this shim's own re-entry override, unchanged. 2. **PATH** — where the App-aware `gh` lives. 3. `T3_GITHUB_REAL_GH` — last resort only, so hosts without a wrapper still work. ## Verification The same command that returned exit 4, under the server's exact environment, after the change: ``` $ .tools/bin/gh pr list --head sync/upstream-48aa875c0 --state all --limit 5 --json number,state [{"number":372,"state":"MERGED"}] ``` Regression test added to `scripts/agent-pre-push.test.mjs` pinning all three tiers of the order; it fails on the pre-fix implementation and passes after. Full file: 26 tests pass. The deploy checkout was patched only to prove the fix live and has been restored to its released state, so the fleet stays consistent with its deployed SHA until this lands. Co-authored by [@patroza](https://github.com/patroza) opened by [Patrick Roza](https://discord.com/users/95218063095377920) in chat thread **Discord** · [Discord](https://discord.com/channels/1083767712431480922/1534783738322485399/1534783738322485399) · [T3](https://t3vm/?thread=584a9ad3-243e-4308-8a13-49acdd758b17) Co-authored-by: omegent-app[bot] <306514130+omegent-app[bot]@users.noreply.github.com> Co-authored-by: Patrick Roza <42661+patroza@users.noreply.github.com>

patroza marked this pull request as ready for review August 6, 2026 10:01

patroza merged commit 62708e8 into fork/devAug 6, 2026
6 of 10 checks passed