[Bug]: 0.0.41-nightly desktop UI "T3 Code could not load." — t3code:// serves truncated asset (SyntaxError: Unexpected end of input) #11523

Activity

1. juliusmarminge commented on Sep 13, 2026

   

   juliusmarminge

   on Sep 13, 2026

   Member

   More actions

   Triage

   Accepted as a critical desktop launch bug. v0.0.41-nightly.20260913.1625 (commit 2db675aef) Linux AppImage opens a window, the backend becomes ready, then the renderer dies and paints “T3 Code could not load.”

   This is not a duplicate of #10719. That issue is a parsed ESM chunk missing export { t }. This one is a parse error (SyntaxError: Unexpected end of input) on the t3code://app path only. It is also not #10517 (blank window because the backend never serves the page).

   T3 Code failed to start. SyntaxError: Unexpected end of input
   source: t3code://app/assets/index-DRGRqw-K.js (2)
   

   The same machine, profile, and launch flags work on v0.0.41-nightly.20260912.1612. Clean --user-data-dir and --appimage-extract both still fail, so this is not a poisoned HTTP cache or squashfs/FUSE truncation.

   What the code does

   Production desktop loads t3code://app/ (apps/desktop/src/window/DesktopWindow.ts → getDesktopUrl). apps/desktop/src/electron/ElectronProtocol.ts registers that scheme (stream: true) and protocol.handles every renderer request by Electron.net.fetching the local backend, then re-wrapping the body to attach CSP:

   return new Response(response.body, { status, statusText, headers });

   The backend serves apps/server/dist/client with HttpServerResponse.stream in apps/server/src/http.ts, behind global HttpMiddleware.compression() (gzip/br, min 1024 bytes).

   Startup is:

   1. Packaged index.html loads the Vite entry (src/bootstrap.ts)
   2. bootstrap.ts does import("./main").catch(showBootError)
   3. apps/web/src/lib/bootError.ts logs T3 Code failed to start. and paints “T3 Code could not load.” (the SyntaxError is DEV-only in the UI, which is why it only appears under --enable-logging)

   The log source: …/index-DRGRqw-K.js (2) is the console.error inside showBootError. That entry module ran. The SyntaxError is from whatever import("./main") fetched — typically the main hashed chunk or another /assets/*.js — not proof that index-DRGRqw-K.js itself was truncated. Chromium often attributes a failed import() to the importer.

   That matches the reporter’s checks: index-DRGRqw-K.js is valid in app.asar (7971 bytes) and over http://127.0.0.1:3773/assets/… (Chrome can load that URL and reach pairing). The HTTP graph is good; the custom-protocol hop is not.

   stream: true plus re-wrapping a net.fetch stream while copying Content-Length / Content-Encoding is a known Electron custom-protocol footgun (truncated body, or gzip/length mismatch after Chromium decodes). #9023 enabled streaming for media; it applies to JS modules too.

   Why this nightly?

   ElectronProtocol.ts and static http.ts are unchanged between 20260912.1612 and 20260913.1625. Electron is still 44.1.0. Desktop commits in the window (#7599 quit timeout, #7110 preview UA, paste-as-text from #11442) are not on the renderer serve path. The web client did change substantially (composer attachments, subagent rows, a11y headings, diffs), so chunk sizes/graphs changed on top of the existing stream proxy. A latent protocol-stream bug becoming 100% on a larger or differently chunked bundle is the best fit.

   Related

   • [Bug]: T3 Code 0.0.40 desktop UI: "T3 Code could not load" #10719 — same boot screen / t3code://app; different error (missing export)
   • [Bug]: Backend startup crashes leave desktop blank with no visible error #10517 — blank window; backend never serves
   • [Bug]: T3 Code opens a blank window when the Linux credential store is locked #9239 / fix(desktop): app no longer opens a blank window when the Linux credential store is locked #9246 — Linux credential-store blank window
   • AppImage auto-update leaves a 0-byte binary and the app never launches again #10685 — AppImage auto-update leaves a 0-byte binary
   • [Bug]: Failed startup session probe bricks the app — fatal, sticky error in root beforeLoad with no recovery #3513 — sticky error after the renderer has loaded
   • fix(media): preview host files and stream videos across clients #9023 — added stream: true (already in the working nightly)
   • Fix Electron dev and packaged renderer startup #3557 — protocol proxy, header stripping, GET retries
   • feat: add inline file previews and attachment chips across surfaces #11265 — CSP frame-src only; already in 20260912.1612
   • feat(desktop): serve packaged renderer locally #8101 — closed; serve packaged renderer from disk instead of proxying HTTP

   No open PR for this truncation.

   Next step

   1. On the failing AppImage, compare all /assets/*.js (especially the target of index-*.js’s import()) over t3code://app vs HTTP vs app.asar — byte length and a tail snippet, not only index-DRGRqw-K.js.
   2. Fix the protocol handler: buffer JS/CSS/HTML (arrayBuffer()), drop stale Content-Encoding, set Content-Length to the decoded size; keep streaming for audio/video only. Optionally revisit feat(desktop): serve packaged renderer locally #8101 (serve packaged files from the asar path).
   3. Check macOS and Windows v0.0.41-nightly.20260913.1625 — same t3code:// path.

   Workaround: v0.0.41-nightly.20260912.1612.
2. juliusmarminge

   added

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

   acceptedfeature request acceptedfeature request accepted

   via-triageFiled through npx t3 triageFiled through npx t3 triage

   on Sep 13, 2026
3. davibarbosa2 commented on Sep 13, 2026

   

   davibarbosa2

   on Sep 13, 2026

   Author

   More actions

   Measured this from the affected build using the renderer's own DevTools (Electron --remote-debugging-port). The source: in the error is misleading: assets/index-DRGRqw-K.js is not the broken file. showBootError lives in that chunk, so the caught SyntaxError is attributed there. The truncated files are the large chunks.

   Fetching each /assets/*.js from the renderer and comparing byteLength to the entry size in app.asar:

   asset	received over t3code://	expected
   assets/main-CFHzQs_8.js	246112	704945
   assets/utils-DmcWaRy7.js	260917	755787
   assets/server-CSx755AA.js	0	19224

   Small assets are intact — assets/index-DRGRqw-K.js is 7971/7971 and its sha256 matches the copy inside app.asar:

   51cfaf46373be9425c39b51bb878ed9aa7e1757dd8367e9067ff8246aba26c99
   

   The same backend serves the full files over its HTTP listener, so the truncation is specific to the t3code:// path and only hits larger bodies:

   $ curl -s -o /dev/null -w '%{size_download}' http://127.0.0.1:3773/assets/main-CFHzQs_8.js
   704945

   Same measurement against the previous nightly (v0.0.41-nightly.20260912.1612), same machine, same flags, same profile setup: 256 assets loaded through t3code://, 0 mismatches, no boot error. The working build even ships larger chunks (utils 755380, main 700010, heic-to ~3 MB), so it is not a simple size limit either.

   Both builds negotiate the same encodings (br/gzip, no zstd), so it does not appear to be zstd:

   # broken build, /assets/utils-DmcWaRy7.js
   req=identity -> content-length: 755787
   req=br       -> content-encoding: br
   req=zstd     -> content-length: 755787   # not compressed
   req=gzip     -> content-encoding: gzip

   So: regression between 20260912.1612 and 20260913.1625 in the delivery of large assets over t3code://, even though nothing landed in apps/desktop/src/electron/ElectronProtocol.ts or apps/server/src/http.ts in that window.

   Minimal way to reproduce the measurement (app launched with --remote-debugging-port=9333), run in the page context via CDP Runtime.evaluate:

   const r = await fetch("t3code://app/assets/main-CFHzQs_8.js");
   (await r.arrayBuffer()).byteLength; // 246112 here, 704945 expected

   Workaround still: use v0.0.41-nightly.20260912.1612.