[Bug]: T3 Code Desktop Windows cant open anymore 0.1.6 #29516

Activity

1. TheDarkSkyXD

   added

   bugSomething is broken or behaving incorrectly.Something is broken or behaving incorrectly.

   needs-triageIssue needs maintainer review and initial categorization.Issue needs maintainer review and initial categorization.

   on Nov 2, 2026
2. TheDarkSkyXD

   changed the title [-][Bug]: T3 Code Desktop Windows cant open anymore 1.0.6[/-] [+][Bug]: T3 Code Desktop Windows cant open anymore 0.1.6[/+] on Nov 2, 2026
3. juliusmarminge

   added

   needs more infoInitial triage showed no bug. Awaiting more infoInitial triage showed no bug. Awaiting more info

   on Nov 2, 2026
4. juliusmarminge commented on Nov 2, 2026

   

   juliusmarminge

   on Nov 2, 2026 – with GitCafe Production

   Member

   More actions

   Thanks for the screenshot. Here's what we ran, on Linux desktop builds (v0.1.6 at 2359643 and current main at 0847a44):

   • v0.1.6 with a fresh T3 home, and a relaunch on an existing one: the backend was ready in 2–5 s and the app opened normally.
   • v0.1.6 with the backend held silent for 70 s: we got exactly your screen ("The server started but did not become ready in time" / "The server wrote no output") at 60 s. When the backend finished starting at about 82 s, the app window opened on its own.
   • Current main with the same 70 s stall: no error screen. The window shows a splash and opens when the backend is ready. Main now waits up to 3 minutes before showing that screen (#26247, #28715; in nightlies, not yet in a stable release).

   So on 0.1.6 this screen means the local server took more than 60 s to answer, without printing anything. To find out why it's slow or stuck on your machine, could you share:

   1. server-child.log, desktop.trace.ndjson and server.trace.ndjson from C:\Users\Admin\.t3\userdata\logs. Traces can include project paths, so look them over before posting.
   2. If you leave the "could not start" window open for 5 minutes, does T3 Code eventually open by itself?
   3. Whether you use the WSL backend, and whether anything changed on the machine since 0.1.6 last opened (Windows or antivirus update, Smart App Control, a moved T3 home).
5. TheDarkSkyXD commented on Nov 2, 2026

   

   TheDarkSkyXD

   on Nov 2, 2026

   Author

   More actions

   If you leave the "could not start" window open for 5 minutes, does T3 Code eventually open by itself? no
   Whether you use the WSL backend, and whether anything changed on the machine since 0.1.6 last opened (Windows or antivirus update, Smart App Control, a moved T3 home). no nothing changed

   t3-logs-redacted.zip
6. juliusmarminge

   added

   needs more infoInitial triage showed no bug. Awaiting more infoInitial triage showed no bug. Awaiting more info

   and removed

   needs more infoInitial triage showed no bug. Awaiting more infoInitial triage showed no bug. Awaiting more info

   on Nov 2, 2026
7. juliusmarminge commented on Nov 2, 2026

   

   juliusmarminge

   on Nov 2, 2026 – with GitCafe Production

   Member

   More actions

   Thanks for the logs. Here's what they show:

   • 0.1.6 has never started on this machine. The in-app update installed at 16:12 UTC on Nov 2. Since then, every launch (16:12, 16:14, 18:35) has started a backend process that stays alive but never begins listening: no output, and its trace stops about 1 second after launch. The 18:35 run was the same process (pid 11896) for 5½ minutes until you closed the window.
   • The version before the update (0.1.3) also started slowly here. It printed "Listening" within seconds, but the health check only answered after a few minutes. 0.1.6 doesn't get that far.
   • We ran the 0.1.6 upgrade migrations on Linux against a 1.5 GB synthetic database. They took about 4 seconds, and a fresh server on current main (9bcf753) listens within a second of finishing them. So far we can't make it hang, and the logs don't show which step it's stuck on.

   To find that step, could you run the server in a terminal so we can see its output live:

   1. Quit T3 Code completely. In Task Manager, check that no t3code / T3 Code processes are left (if one is, note that, then end it).
   2. In PowerShell, run:

      & "$env:USERPROFILE\.t3\bin\t3.cmd" serve --log-level debug

      This starts the same 0.1.6 server the app uses, on the same data.
   3. Leave it for 10 minutes, or until it prints Listening on …. Then paste everything it printed, or the last 50 lines if it's long. Press Ctrl+C to stop it.

   Also helpful:

   • The size of C:\Users\Admin\.t3\userdata\statev2.sqlite and of statev2.sqlite-wal next to it, if that file exists.
   • What F: is (internal disk, external USB drive, or network share), and whether it was connected. Your older logs show git commands timing out on projects in F:\REPOS.
8. TheDarkSkyXD commented on Nov 2, 2026

   

   TheDarkSkyXD

   on Nov 2, 2026

   Author

   More actions

   Thanks, ran it. It wasn't hung: migration 72 took almost 5 minutes on this machine, then it started normally.

   Run: t3.cmd serve --log-level debug, no T3 Code processes left beforehand (none to end). Started 19:28:58 UTC, printed Listening on http://127.0.0.1:3773 at 19:34:15 UTC (5m17s), then I stopped it.

   Migration timings (local time, UTC−6):

   [13:29:01.191] Running migration 72_WaitingLinkRequestIndex
   [13:33:46.534] Running migration 73_ActiveTurnItemIndexes <- 72 took 4m45s
   [13:33:53.909] Running migration 74_ExcludeAttachmentPlaceholdersFromSearch <- 73 took 7.4s
   [13:33:53.963] Running migration 75_SubagentDeliveryState
   [13:34:09.779] Running migration 76_ProjectionProjectsPinArchive <- 75 took 15.8s
   [13:34:09.791] Migrations complete
   [13:34:10.030] INFO Migrations ran successfully (70..76)
   [13:34:15.043] startup phase: starting keybindings runtime
   [13:34:15.096] INFO Listening on http://127.0.0.1:3773
   70 and 71 took a few ms each. Nothing was printed before Running migration 70, and stderr was empty. The only other output after Listening was a WARN that default keybindings are already defined in my keybindings.json.

   While 72 was running I sampled the process for 15s: about 425 MB read in about 109k read ops (≈28 MB/s, 4 KB reads), 5 MB written, 0.5s CPU. So it was bound by random reads, not CPU.

   Database:

   statev2.sqlite: 12,502,220,800 bytes (12.5 GB), so about 8× your 1.5 GB synthetic DB
   statev2.sqlite-wal: 17,884,952 bytes (17.9 MB)
   Both were the same size after the migrations as before.
   F: is an external USB drive: a 2 TB SSD in an ASMedia ASM1156 USB enclosure, NTFS. It was connected and healthy during this run. The database is on C:, not F:.

   I'm guessing the app launches since the update never got past 72 because the desktop backend readiness timeout (I saw Timed out after 60000ms waiting for desktop backend readiness in the desktop trace) or me closing the window interrupted it, so it rolled back each time. Now that the migrations are committed, the next app launch should get past this.
9. juliusmarminge

   removed

   needs more infoInitial triage showed no bug. Awaiting more infoInitial triage showed no bug. Awaiting more info

   on Nov 2, 2026