Before submitting
Area
apps/desktop — Windows auto-updater
Environment
- Windows 11 x64
- T3 Code Nightly
- Observed updating from
0.0.29-nightly.20260722.878 to 0.0.29-nightly.20260723.880
Problem
After the update has downloaded, clicking Restart to Update completely closes T3 Code. No updater window, progress indicator, tray status, or other visible feedback appears while installation continues in the background.
During the observed 878 → 880 update, T3 remained visually absent for roughly eight minutes (approximately 12:22:37–12:30:46) before relaunching successfully. A less technical user would reasonably assume the update had crashed, been abandoned, or that they needed to launch/reinstall the app manually.
The delay was real work rather than a hang: the background installer extracted roughly 14,500 files and then copied the unpacked resources before T3 relaunched. The issue is that none of this progress is visible.
Steps to reproduce
- Run T3 Code Nightly on Windows 11.
- Download an available update from within T3.
- Click Restart to Update.
- Observe that every T3 window closes and no installation UI is shown for several minutes.
- T3 eventually relaunches after the silent installation finishes.
Actual behaviour
The application disappears completely while a long-running silent installer works in the background. There is no indication that the update is still progressing.
Expected behaviour
Keep a small persistent Updating T3 Code… window or native installer progress UI visible until relaunch. At minimum, warn before shutdown that installation may take several minutes and that T3 will reopen automatically.
Additional context
The desktop update path currently calls quitAndInstall with isSilent: true, which appears consistent with the observed behaviour:
https://github.com/pingdotgg/t3code/blob/b44ed835c63caafae619e303ca019a251c2698b2/apps/desktop/src/updates/DesktopUpdates.ts
Related but previously completed issue: #1204. That issue addressed update discoverability/confirmation; this report specifically concerns the multi-minute period after shutdown where Windows shows no evidence that installation is still running.
I have only reproduced this on Windows and cannot confirm whether macOS behaves similarly.
Before submitting
Area
apps/desktop — Windows auto-updater
Environment
0.0.29-nightly.20260722.878to0.0.29-nightly.20260723.880Problem
After the update has downloaded, clicking Restart to Update completely closes T3 Code. No updater window, progress indicator, tray status, or other visible feedback appears while installation continues in the background.
During the observed 878 → 880 update, T3 remained visually absent for roughly eight minutes (approximately 12:22:37–12:30:46) before relaunching successfully. A less technical user would reasonably assume the update had crashed, been abandoned, or that they needed to launch/reinstall the app manually.
The delay was real work rather than a hang: the background installer extracted roughly 14,500 files and then copied the unpacked resources before T3 relaunched. The issue is that none of this progress is visible.
Steps to reproduce
Actual behaviour
The application disappears completely while a long-running silent installer works in the background. There is no indication that the update is still progressing.
Expected behaviour
Keep a small persistent Updating T3 Code… window or native installer progress UI visible until relaunch. At minimum, warn before shutdown that installation may take several minutes and that T3 will reopen automatically.
Additional context
The desktop update path currently calls
quitAndInstallwithisSilent: true, which appears consistent with the observed behaviour:https://github.com/pingdotgg/t3code/blob/b44ed835c63caafae619e303ca019a251c2698b2/apps/desktop/src/updates/DesktopUpdates.ts
Related but previously completed issue: #1204. That issue addressed update discoverability/confirmation; this report specifically concerns the multi-minute period after shutdown where Windows shows no evidence that installation is still running.
I have only reproduced this on Windows and cannot confirm whether macOS behaves similarly.