@Srijan-D When the flicker happened, was anything else running in the app (an agent turn streaming, a large thread open behind Settings, or many threads), and does the flicker still happen when you toggle Labs switches during an update download with no turns running?
[Bug]: Settings toggles get stuck and flicker while the desktop app downloads an update#33853
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
- In the desktop app, let it start downloading an available update.
- While it downloads, open Settings → Labs and toggle a few switches (e.g. Boring sidebar, Two-line folder rows, Guest links).
Expected behavior
Each toggle flips once and saves right away, the same as when no update is downloading.
Actual behavior
While the update downloads, the toggles get stuck and flicker. They don't settle. Once the download finishes, they work normally again.
My app's own logs from one occurrence (local time, IST, 2026-11-10) show the same timing:
- 17:26:55–17:27:19: update
0.1.8-nightly.20261109.4429downloads (93desktop.updates.handleDownloadProgressspans indesktop.trace.ndjson). - During the download: no
server.updateSettingsspans reach the server. - 17:27:49: five
server.updateSettingsspans arrive at once, each taking 4–15 ms. The server answers fast, so the saves look held up on the client side and then sent together. - Renderer memory (
renderer-history.ndjsonsamples): about 466–470 MB for the five minutes before, then 469 MB at 17:26:36, 638 MB at 17:27:06, and 1,097 MB at 17:27:36. - 17:27:56: the renderer is destroyed and recreated for the install. Memory goes back to about 380–480 MB.
What the logs don't show:
- The flicker itself.
- Which settings those five saves changed.
Some Labs toggles may also save only on the client and never reach the server. In DesktopUpdates.ts, download progress is already throttled (shouldBroadcastDownloadProgress) before it is sent to the window. So the cause may be in how the renderer handles each update-state message, given the memory jump, but I have not confirmed that or reproduced it on purpose.
Impact
Minor bug or occasional failure
Version or commit
Desktop 0.1.8-nightly.20261106.4275, while it downloaded 0.1.8-nightly.20261109.4429
Environment
macOS 15.1, T3 Code desktop (nightly), Apple Silicon
Screenshots, recordings, or supporting files
No recording yet. The app is up to date now, so I can't trigger a download on demand. I'll add a screen recording of the flicker the next time an update downloads.
Workaround
Wait for the update download to finish before changing settings.
Investigated and drafted by Claude Code (claude-opus-5-5) running inside T3 Code.
Synced from GitHub
No agent turn was running. My logs show no turn activity then. But a provider update was running at the same time. Just before toggling, I had clicked the sidebar's "Check for updates" button for providers. The nightly app update downloaded on its own.
From 17:26:54 to 17:27:49 IST the server pushed a provider-update status change about once a second, and my settings saves only went through at 17:27:49, right when that stopped. The app update finished downloading earlier, at 17:27:19. So the provider update may be the trigger rather than the app download. I'll retest both on their own and record it.
[GPT-6.1 Sol][Codex] on behalf of shivam.
Julius already has the fix in https://github.com/pingdotgg/t3code/pull/33875. The reporter’s follow-up identifies provider updates as the likely trigger: settings saves remained blocked after the desktop download ended. Stopping this duplicate investigation and handing the issue to that PR.