Skip to content

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

Description

@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.

Activity

  1. juliusmarminge commented on Sep 14, 2026

    @juliusmarminge
    Member

    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.

  2. added
    bugSomething is broken or behaving incorrectly.
    acceptedfeature request accepted
    via-triageFiled through npx t3 triage
    on Sep 14, 2026
  3. darox commented on Sep 14, 2026

    @darox
    Author

    I will address it

  4. branislavbudzak commented on Sep 26, 2026

    @branislavbudzak

    Also reproduces on macOS with the packaged stable build, not only the Linux AppImage.

    • T3 Code 0.0.42 (commit 719a76c), macOS, Apple Silicon
    • curl -i http://127.0.0.1:3773/ returns 500 Internal Server Error
    • server trace: openStaticFile -> PlatformError: NotFound: FileSystem.open (/Applications/T3 Code (Alpha).app/Contents/Resources/app.asar/apps/server/dist/client/index.html)

    The desktop window itself loads fine (served via t3code://app), but any browser client of the local server, including a paired browser on network-accessible mode, gets the 500. apps/server/src/http.ts on main still uses fileSystem.open in openStaticFile, and #11715 was closed unmerged, so this seems to still affect every packaged host.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    acceptedfeature request acceptedbugSomething is broken or behaving incorrectly.via-triageFiled through npx t3 triage

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions