[Bug]: Linux AppImage 0.0.41-nightly.20260914.1687 returns HTTP 500 — static handler uses fs.open on app.asar

[darox]

Summary

The Linux AppImage starts, but the backend returns HTTP 500 for GET /. The desktop UI cannot load.

Version

• T3 Code: 0.0.41-nightly.20260914.1687
• Package: Linux x86_64 AppImage, 188708343 bytes
• Electron 44.1.0, Node 24.19.0, Chrome 152.0.7977.65
• Ubuntu 26.04.1 LTS, GNOME on Wayland

Steps to reproduce

1. Run T3-Code-0.0.41-nightly.20260914.1687-x86_64.AppImage.
2. Wait for backend ready in ~/.local/state/t3code/t3code.log.
3. Run curl -i http://127.0.0.1:3773/.

Actual result

HTTP/1.1 500 Internal Server Error
content-type: text/plain
content-length: 21

Internal Server Error

Expected result

The backend returns the web client. The desktop UI loads.

Cause

The static handler calls FileSystem.open on this path:

/tmp/.mount_T3-Cod.../resources/app.asar/apps/server/dist/client/index.html

The Electron asar layer fails the open call with ENOENT:

openStaticFile -> PlatformError: NotFound: FileSystem.open (.../app.asar/apps/server/dist/client/index.html)
ENOENT, apps/server/dist/client/index.html not found in .../app.asar

The file is present in the archive. fs.statSync returns size 20143, and fs.readFileSync returns valid HTML. fs.openSync and fs.promises.open fail with ENOENT. Electron asar support implements stat and readFile, but not open.

Regression

PR #9669 added the file-handle streaming path. That code returns 500 on PlatformError. The failure occurs when the client files are inside app.asar, as in the AppImage build.

This is not #11523. #11523 reports truncated assets on the t3code:// path.

Suggested fix

Read the file with FileSystem.readFile, or mark the client directory as unpacked in the AppImage build.

Workaround

Run an older AppImage.

[juliusmarminge]

Triage

Accepted as a critical Linux AppImage host bug. v0.0.41-nightly.20260914.1687 (c07575f573dd) starts, logs backend ready, then GET / on the backend is HTTP 500. The desktop window cannot load on this nightly.

This is not a duplicate of #11523. That issue is t3code://app truncating large JS chunks while HTTP returned 200. This one is the HTTP static handler itself failing on FileSystem.open against app.asar. It is also not #10719 (ESM export mismatch) or #10517 (backend crash / blank window).

openStaticFile -> PlatformError: NotFound: FileSystem.open
(.../app.asar/apps/server/dist/client/index.html)
ENOENT, apps/server/dist/client/index.html not found in .../app.asar

fs.stat / fs.readFile see a real 20 KB index.html. fs.open / fs.promises.open do not.

What the code does

apps/server/src/http.ts (openStaticFile, from #9669) stats the file, then FileSystem.opens it and streams 64 KB chunks. PlatformError is mapped to Internal Server Error (500). Effect’s Node layer uses callback fs.open (.repos/effect-smol/packages/platform/node-shared/src/NodeFileSystem.ts).

Linux AppImages pack the web client into one app.asar (scripts/build-desktop-artifact.ts). There is no asarUnpack for apps/server/dist/client. The backend is ELECTRON_RUN_AS_NODE=1 on the Electron binary (apps/desktop/src/backend/DesktopBackendConfiguration.ts), so it hits Electron’s asar-patched fs.

On Electron 44.1.0, fs.open of a packed asar entry goes through temp extraction (copyFileOut). readFile / stat read the archive directly. That matches this stack: file is present, open is ENOENT. Electron 45 serves asar fds from the archive (electron#52833); 44 keeps the old path (electron#52804).

http.ts did not change between 20260913.1625 and 1687. #11523’s HTTP 200 on assets is compatible with a file- or extraction-specific open failure (this report only shows GET /). On this nightly the renderer still proxies t3code://app → http://127.0.0.1:3773/ (DesktopApp.ts before #9194). #9194 (cba7dd778, after 1687) serves the packaged renderer with FileSystem.readFile and unblocks the local window. Pairing, LAN, Tailscale, and other HTTP clients still hit openStaticFile and stay broken. macOS app.asar and Windows server.asar use the same handler.

No open PR fixes this.

Next step

1. In openStaticFile, fall back to FileSystem.readFile when open fails (or when the path contains .asar). Keep handle streaming on a real filesystem. Unpacking apps/server/dist/client/** is an alternative, not required if the fallback exists.
2. Add a test where stat/readFile succeed and open returns ENOENT — response must be 200, not 500.
3. On 1687, check GET /assets/* as well as GET /. Check macOS / Windows packaged hosts.

Workaround: an older AppImage. After #9194, a newer nightly may open the local window while HTTP static serving is still 500.

[darox]

I will address it