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

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

when i try to start the app it wont start and this is what i get

Expected behavior

to start the app

Actual behavior

it wont start

Impact

Blocks work completely

Version or commit

0.1.6

Environment

windows

Logs or stack traces

Screenshots, recordings, or supporting files

No response

Workaround

No response

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:

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.
If you leave the "could not start" window open for 5 minutes, does T3 Code eventually open by itself?
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).

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

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:

Quit T3 Code completely. In Task Manager, check that no t3code / T3 Code processes are left (if one is, note that, then end it).
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.
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.

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.

[GPT-6.1 Sol][Codex] on behalf of shivam.

I tested the official 0.1.6 ARM64 desktop payload, commit 2359643cffa6ba9ee84d6f2694b935de54a8013e, on Windows 11 Pro ARM64 build 26200. An isolated 231 MB synthetic database with 150,000 turn-item rows upgraded through migrations 72–76 and opened the app. Migration 72 took 1.54 seconds. After a full quit, the same home reopened normally without rerunning those migrations; all rows remained intact. This smaller fixture does not establish what happens with your 12.5 GB database or reproduce the five-minute scan.

Does the desktop now open after the CLI run that completed your migrations? If it still fails, please share the current app version and fresh desktop.trace.ndjson and server.trace.ndjson from %USERPROFILE%\.t3\userdata\logs after one failed launch. Include server-child.log if present, and review the files for private paths or credentials before uploading.

Navigation Menu

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

Before submitting

Area

Steps to reproduce

Expected behavior

Actual behavior

Impact

Version or commit

Environment

Logs or stack traces

Screenshots, recordings, or supporting files

Workaround

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Before submitting

Area

Steps to reproduce

Expected behavior

Actual behavior

Impact

Version or commit

Environment

Logs or stack traces

Screenshots, recordings, or supporting files

Workaround

Activity

juliusmarminge commented on Nov 2, 2026

TheDarkSkyXD commented on Nov 2, 2026

juliusmarminge commented on Nov 2, 2026

TheDarkSkyXD commented on Nov 2, 2026

shivamhwp commented on Nov 4, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions