[Bug]: Linux AppImage: every t3 CLI call writes a new compile cache that is never reused #33874

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#

1. On Linux, install the desktop AppImage and install the t3 command from Settings. This writes the shim ~/.t3/bin/t3.
2. Open a shell that does not have APPIMAGE in its environment, such as a normal terminal, a systemd user service or cron.
3. Run a CLI command that loads the CLI bundle a few times, for example t3 thread show <thread-id> --json --messages 2. The command doesn't need to succeed: it also reproduces when the server is not running.
4. Count the cache files with find ~/.cache/t3code/compile-cache -type f | wc -l.

Expected behavior#

enableCliCompileCache() is meant to skip AppImage installs ("AppImage paths change each launch"). The CLI should write nothing to ~/.cache/t3code/compile-cache, or it should reuse a stable cache.

Actual behavior#

Every invocation writes about 16 new files (about 3 MB) under compile-cache/v24.22.1-x64-<hash>-<uid>/. Each entry embeds that run's /tmp/.mount_t3code<random> path, so no entry is ever reused and the directory grows without bound. A non-interactive process that polls t3 grew it to about 200k files in six days: ~95 GB by du, ~40 GB on disk with btrfs zstd. That filled the disk.

Impact#

Major degradation or frequent failure

Version or commit#

Desktop 0.1.8-nightly.20261109.4399

Environment#

Fedora 44 (Linux 7.1, x86_64), GNOME 50 Wayland, desktop AppImage (Electron 44.10.1, Node 24.22.1), btrfs with zstd

Logs or stack traces#

$ ls ~/.cache/t3code/compile-cache
server  v24.22.1-x64-80d1f614-1000  v24.22.1-x64-e015eff9-1000
$ find ~/.cache/t3code/compile-cache/v24.22.1-x64-80d1f614-1000 -type f | wc -l
108167
$ find ~/.cache/t3code/compile-cache/v24.22.1-x64-e015eff9-1000 -type f | wc -l
95231
# Each `t3` invocation's entries reference a different /tmp/.mount_t3code<random> path.

Screenshots, recordings, or supporting files#

No response

Workaround#

Cause

• apps/desktop/src/app/DesktopCliShim.ts mounts the AppImage with --appimage-mount and then runs "$mount/t3code" .../apps/server/dist/bin.mjs directly. The AppImage runtime therefore never sets APPIMAGE.
• apps/server/src/cliCompileCache.ts skips the cache only when process.env.APPIMAGE is set, so the guard never fires.
• The guard only looks like it works when the caller happens to inherit APPIMAGE from another AppImage, for example a terminal running inside a different AppImage-packaged app.

Files written per call, measured with the same command, a clean environment, and the bundled CLI run exactly as the shim runs it:

Environment	Files written
No APPIMAGE (what the shim produces)	16
APPIMAGE=<path to the t3code AppImage>	0
NODE_DISABLE_COMPILE_CACHE=1	0

Possible fixes:

• Export APPIMAGE="$app" in the Linux shim before running the bundled CLI.
• Set NODE_DISABLE_COMPILE_CACHE=1 in the shim.
• Have cliCompileCache.ts detect an AppImage mount from its own entry path instead of relying on the environment.

Existing installs would also benefit from pruning stale compile-cache/v* directories.

Workaround#

• Set NODE_DISABLE_COMPILE_CACHE=1 in the environment of anything that calls t3 repeatedly. With it, the CLI writes 0 files per call.
• Delete ~/.cache/t3code/compile-cache/v* and keep compile-cache/server/.