[Bug]: Local backend becomes CPU-bound and unresponsive during idle VCS/provider refreshes, causing reconnects

[causercode]

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/desktop

Steps to reproduce

1. Launch T3 Code 0.0.29 with a new, isolated T3 profile containing no prior app state.
2. Add one ordinary local Git repository and retain one thread.
3. Set the automatic Git fetch interval to 0.
4. With Sidebar V2 disabled, leave the app idle with no agent or thread running.
5. Enable Settings → Beta features → Sidebar V2.
6. Fully restart T3 Code.
7. Leave the app idle again with no agent or thread running.
8. Observe the slow-request status and connection notifications.

The repository is on a local disk and does not require a remote or network connection to reproduce the behavior.

Expected behavior

Sidebar V2 should not continually schedule duplicate vcs.listRefs calls while the app is idle. Requests for the same repository should be deduplicated, cached, or otherwise bounded, and should not prevent the local environment health endpoint from responding.

Actual behavior

After Sidebar V2 is enabled, many concurrent vcs.listRefs requests appear while the app is idle. The requests eventually time out, and T3 Code can then display a reconnect notification because its local environment endpoint does not respond within 10 seconds.

This reproduced in a clean profile with only one project and one thread. Disabling automatic Git fetch did not prevent it. With Sidebar V2 disabled, I did not observe the request storm or reconnects during the same clean-profile test.

Sanitized measurements from one occurrence:

# Sidebar V2 enabled; app idle; automatic Git fetch disabled
15 vcs.listRefs requests started within about 8 seconds

Sanitized server-trace counts over roughly 2 minutes:
ws.rpc.vcs.listRefs: 140 spans
runGitCommand: 768 spans
visible request durations: 24–32 seconds
longest visible request: about 32.2 seconds

Representative sanitized failure:
VcsProcessTimeoutError: VCS process timed out in
GitVcsDriver.detectRepository.root: git (<local-repo>) after 30000ms

Follow-on notification:
Failed to connect. Reconnecting...
Remote environment endpoint http://127.0.0.1:3773/.well-known/t3/environment
timed out after 10000ms.

As a comparison, git status --porcelain=v1 completes in about 0.1 seconds for the same repository when run outside T3 Code.

Impact

Major degradation or frequent failure

Version or commit

T3 Code 0.0.29

Environment

• Windows x64 desktop app - Codex provider - Codex CLI 0.145.0 - New isolated T3 profile - One local Git repository

Logs or stack traces

Screenshots, recordings, or supporting files

No response

Workaround

Disable Sidebar V2 and use the original sidebar. Setting the automatic Git fetch interval to 0 alone does not resolve the problem.

Additional context

I selected apps/desktop because this was reproduced in the installed desktop app and the visible connection failure involves its managed local environment endpoint. The underlying cause may cross into apps/web (Sidebar V2 request scheduling) or apps/server (VCS request handling), so please reclassify it if appropriate.

The behavior appears to originate in Sidebar V2's repository/ref refresh activity and then overload the local backend sufficiently to cause the reconnect notification. I have intentionally included only manually sanitized statistics and excerpts because raw provider and server logs can contain local paths, repository names, commands, thread content, and other private project information.

[causercode]

Update: I have now reproduced the same local-environment timeout after switching back to Sidebar V1, with automatic Git fetch still set to 0.

This means Sidebar V2 appears to amplify or trigger the problem more readily, but it is not the sole condition.

During the Sidebar V1 occurrence, a sanitized live check showed:

http://127.0.0.1:3773 accepted a TCP connection but returned no HTTP
response before the client timeout.

The process owning port 3773 continuously used approximately one full
CPU core while the application was idle.

Recent sanitized server-trace activity included:
shell.isExecutableFile: 4,860 spans
runGitCommand: at least 156 spans
GitVcsDriver.listRefs.branchNoColor: 41 spans

Some executable/command-resolution operations took approximately
15–19 seconds.

The visible notification remained:

Failed to connect. Reconnecting...
Remote environment endpoint http://127.0.0.1:3773/.well-known/t3/environment
timed out after 10000ms.

The endpoint uses the numeric loopback address, and the TCP connection
itself succeeds, so this looks like the local backend becoming
CPU-bound or unresponsive rather than an external network or DNS
failure.

[causercode]

#PR #4778 appears to target the same failure I reproduced. My trace showed 4,860 shell.isExecutableFile spans, at least 156 Git commands, sustained backend use of one CPU core, and the loopback environment endpoint accepting connections without responding. The problem also occurred with Sidebar V1, which is consistent with the PR’s shared/server-level diagnosis.

[NateZwainleskPLA]

Follow-up after installing 0.0.30-nightly.20260728.936, which includes the changes from #4727 the disconnect symptom still occurs, but the trace profile has changed substantially.

Across roughly two minutes of server traces:

vcs.listRefs: 76 spans
shell.isExecutableFile: 106,980 spans

During one occurrence, GET /api/orchestration/shell ran for approximately 18 seconds before the client cancelled it with HTTP 499. The backend process remained alive, and the renderer still had established loopback connections to 127.0.0.1:3773.

This suggests #4727 successfully reduced the Git-ref refresh storm, but that storm was not the only cause of the visible connection errors. Command/editor discovery is now the dominant activity, consistent with the executable-probe problem addressed by #4778

In other words, the remaining failure still appears to be backend starvation or excessive request latency—not an actual loss of the local socket connection.

Diagnostics were collected from my local T3 Code installation and analyzed with assistance from Codex (GPT-5.6 Sol)

[haye-go]

Probably same issue, I used codex to explore and read logs. Here's info from me. On windows, it's causing constant disconnection (probably due to overload), whether using the app or running npx and using on browser. I was only working on a single thread and a single project and it is almost unfunctionable (constantly giving localhost disconnected error).

-- from codex --
It is WebSocket-related, but not a WebSocket connection limit.

I found only about seven established connections to port 3773—far below Windows/browser socket limits. The problem is that T3 multiplexes many logical subscriptions over those few connections:

• Previously observed 225 subscribeThread subscriptions
• Reconnects appear to create/replay duplicate subscriptions
• Those subscriptions trigger hundreds of repeated Git/database operations
• The backend becomes CPU/memory saturated
• Even the ordinary HTTP environment endpoint now times out after 12 seconds
• Eventually Node reaches 4 GB and crashes

So the likely bug is a T3 subscription/reconnect fan-out or cleanup leak, amplified by your 677 live tasks and 1.8 million stored events—not a WebSocket quota.

Right now PID 57488 still owns and listens on port 3773, but it cannot answer. Restarting alone will repeat the cycle until the live-task load is reduced or the database is isolated.

---

A more specific defect is visible now: every task subscription repeatedly executes
SELECT ... FROM orchestration_events
WHERE sequence > ?
ORDER BY sequence ASC
LIMIT ?
There is no task-ID filter in that query. Each logical task subscription scans the shared global event stream and filters later. I’m quantifying how many copies each reconnect creates and which VCS subscriptions accompany them.

Ran $logs='C:\Users\(redacted)\.t3\userdata\logs'; $cutoff=[decimal]([DateTimeOffset]::Parse('2026-07-29T04:09:47Z').ToUnixTimeMilliseconds())*1000000; $rows=[System.Collections.Generic.List[object]]::new(); Get-ChildItem -LiteralPath $logs -Filter 'server.trace.ndjson*' -File | ForEach-Object { $file=$_.FullName; rg --fixed-strings '"rpc.method"' $file 2>$null | ForEach-Object { try { $o=$_|ConvertFrom-Json -Depth 20; if($o.type -eq 'effect-span' -and [decimal]$o.startTimeUnixNano -ge $cutoff){ $rows.Add([pscustomobject]@{TraceId=$o.traceId; Parent=$o.parentSpanId; Method=$o.attributes.'rpc.method'; Start=[decimal]$o.startTimeUnixNano; Duration=[double]$o.durationMs; Exit=$o.exit._tag}) } } catch {} } }; Write-Output ('RPC_SPANS=' + $rows.Count); Write-Output 'METHOD_TOTALS'; $rows|Group-Object Method|Sort-Object Count -Descending|Select-Object Count,Name|Format-Table -AutoSize; Write-Output 'RECONNECT_BATCHES'; $rows|Group-Object TraceId|ForEach-Object { $g=$_.Group; [pscustomobject]@{TraceId=$_.Name; StartUtc=[DateTimeOffset]::FromUnixTimeMilliseconds([long](($g|Measure-Object Start -Minimum).Minimum/1000000)).UtcDateTime.ToString('HH:mm:ss.fff'); Total=$g.Count; ThreadSubs=@($g|Where-Object Method -eq 'orchestration.subscribeThread').Count; VcsListRefs=@($g|Where-Object Method -eq 'vcs.listRefs').Count; VcsStatus=@($g|Where-Object Method -eq 'vcs.subscribeStatus').Count; ShellSubs=@($g|Where-Object Method -eq 'orchestration.subscribeShell').Count; ParentConnections=@($g.Parent|Sort-Object -Unique).Count; MaxDurationMs=[math]::Round(($g|Measure-Object Duration -Maximum).Maximum) } }|Sort-Object StartUtc|Format-Table -AutoSize in 2s

The subscription set is now identifiable:
Exactly 10 task subscriptions are recreated per WebSocket connection.
There have been five connection generations, giving 50 task-subscription instances.
The much larger explosion is vcs.listRefs: 4,741 RPC calls, including 4,424 on the first connection.
There are also 105 source-control status subscriptions.
Next I’m mapping those VCS calls to repository paths and timing waves; that will identify which project subscription is multiplying.

Ran $logs='C:\Users\(redacted)\.t3\userdata\logs'; $cutoff=[decimal]([DateTimeOffset]::Parse('2026-07-29T04:09:47Z').ToUnixTimeMilliseconds())*1000000; $git=[System.Collections.Generic.List[object]]::new(); $rpc=[System.Collections.Generic.List[object]]::new(); Get-ChildItem -LiteralPath $logs -Filter 'server.trace.ndjson*' -File | ForEach-Object { $file=$_.FullName; rg -e '"git.cwd"' -e '"rpc.method":"vcs.listRefs"' -e '"rpc.method":"subscribeVcsStatus"' $file 2>$null | ForEach-Object { try{$o=$_|ConvertFrom-Json -Depth 20;if([decimal]$o.startTimeUnixNano -ge $cutoff){if($o.attributes.'git.cwd'){$git.Add([pscustomobject]@{TraceId=$o.traceId;Cwd=$o.attributes.'git.cwd';Operation=$o.attributes.'git.operation';Start=[decimal]$o.startTimeUnixNano;Duration=[double]$o.durationMs;Exit=$o.exit._tag})};if($o.attributes.'rpc.method'){$rpc.Add([pscustomobject]@{TraceId=$o.traceId;Method=$o.attributes.'rpc.method';Start=[decimal]$o.startTimeUnixNano;Duration=[double]$o.durationMs;Exit=$o.exit._tag})}}}catch{}} }; Write-Output ('GIT_SPANS=' + $git.Count); Write-Output 'GIT_BY_REPOSITORY'; $git|Group-Object Cwd|ForEach-Object{[pscustomobject]@{Count=$_.Count;Cwd=$_.Name;Failed=@($_.Group|Where-Object Exit -ne 'Success').Count;TotalSeconds=[math]::Round((($_.Group|Measure-Object Duration -Sum).Sum/1000),1)}}|Sort-Object Count -Descending|Select-Object -First 20|Format-Table -AutoSize; Write-Output 'TOP_GIT_OPERATIONS'; $git|Group-Object Operation|ForEach-Object{[pscustomobject]@{Count=$_.Count;Operation=$_.Name;Failed=@($_.Group|Where-Object Exit -ne 'Success').Count}}|Sort-Object Count -Descending|Select-Object -First 20|Format-Table -AutoSize; Write-Output 'VCS_RPC_BY_TRACE'; $rpc|Group-Object TraceId|ForEach-Object{$g=$_.Group;[pscustomobject]@{TraceId=$_.Name;ListRefs=@($g|Where-Object Method -eq 'vcs.listRefs').Count;StatusSubs=@($g|Where-Object Method -eq 'subscribeVcsStatus').Count;Failed=@($g|Where-Object Exit -ne 'Success').Count}}|Sort-Object ListRefs -Descending|Format-Table -AutoSize; Write-Output 'LISTREFS_30S_WAVES'; $rpc|Where-Object Method -eq 'vcs.listRefs'|Group-Object { [long]([math]::Floor(([double]$_.Start/1000000000)/30)*30) }|ForEach-Object{[pscustomobject]@{Utc=[DateTimeOffset]::FromUnixTimeSeconds([long]$_.Name).UtcDateTime.ToString('HH:mm:ss');Count=$_.Count;Failed=@($_.Group|Where-Object Exit -ne 'Success').Count}}|Sort-Object Utc|Format-Table -AutoSize in 6s

The multiplying subscription is now isolated to one repository:
28,784 of 28,801 Git spans target C:(project folder redacted).
Each WebSocket reconnect creates 21 subscribeVcsStatus subscriptions and 10 task subscriptions.
vcs.listRefs accelerates from 2 calls per 30 seconds to roughly 190 per 30 seconds.
Those calls expand into six Git commands each, producing 137,661 seconds of cumulative Git work.
Other repositories account for only 17 Git spans total.
I’m now joining the database metadata for that checkout to identify the exact 10 live tasks and 21 VCS-status consumers associated with it.

The hot checkout belongs to project (project folder redacted) with 18 live tasks. One task explicitly uses that worktree (O5 Diagnose AI Sidebar UX), while the remaining project tasks inherit the same workspace root. The 10 subscribed tasks are likely the currently loaded/recent subset rather than all 18; I’m extracting their IDs from the snapshot request paths and matching their titles.

The server implementation confirms that subscribeVcsStatus is supposed to deduplicate its 21 consumers into one poller keyed by normalized checkout path. That part is noisy but not the 4,700-call explosion. The runaway operation is a separate non-streaming RPC, vcs.listRefs, initiated repeatedly by the desktop UI. I’m locating the client hook that retries it so we can identify the feedback loop.

The client code exposes the concrete feedback loop: every branch-list atom calls vcs.listRefs every five seconds. With 21 live atom variants for the same checkout, that predicts 4.2 RPCs/sec—matching the observed rate almost exactly. Each RPC runs roughly six Git commands, so T3 schedules about 25 Git commands/sec against one repository before slowdown.

The “21” is now explained by the UI structure: each of ten visible sidebar task rows asks for VCS status twice—once in the row and once in its status-indicator component—and the active task view adds another consumer. I’m verifying whether the shared atom layer deduplicates identical {cwd} requests; the trace indicates it does not, even though the server later coalesces their remote poller.

The status-subscription count is partly a symptom, but the source code shows the destructive mechanism is branch-reference polling. Each distinct branch-query key remains alive for five minutes and revalidates every five seconds. I’m checking the pagination hook for an automatic “load next page” loop, because that could continuously create new retained pollers even without user interaction.

[haye-go]

#4727 successfully eliminated the runaway ref-polling/OOM mechanism.

However, the remaining run shows:

• 30,313 shell.isExecutableFile spans
• 328 Git commands spread across many repositories
• 63 VCS-status subscriptions over three connection generations
• Continued reconnects despite normal memory usage

That maps directly to [PR #4778](#4778), which:

• stops tracing every Windows PATH/PATHEXT executable probe;
• caches command-path resolutions for 30 seconds;
• globally limits concurrent Git processes to 4–16.

Therefore:

• Fix Git ref refresh resource storms #4727 fixes the original catastrophic Git-ref storm.
• perf: stop tracing every command-path probe and bound git spawns #4778 is still needed to address the remaining Windows backend starvation.
• They are complementary, not alternatives.
• perf: stop tracing every command-path probe and bound git spawns #4778 is currently open and was based on code from before Fix Git ref refresh resource storms #4727 merged, so it still needs integration/rebase testing.

Even after #4778, further efficiency work would still be worthwhile—especially deduplicating the ten task event-stream subscriptions and avoiding status checks for invisible projects—but those are secondary now, not the present dominant failure.