Skip to content

[Bug]: Linux AppImage: the t3 launcher still points at the old AppImage after an app update, and opening the app does not fix it #31507

Open

Description

@iurii-provizio

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 (AppImage), install the t3 command from Settings. ~/.t3/bin/t3 is written with app='/home/<user>/.local/bin/T3-Code-<old>-x86_64.AppImage' and linked from ~/.local/bin/t3.
  2. Let the app update itself. The updater writes T3-Code-<new>-x86_64.AppImage and removes the old file.
  3. Open the updated app, then run t3 --version in a terminal.

Expected behavior

Opening the updated app rewrites the launcher to the new AppImage, as the launcher's own message promises: "T3 Code has moved or been removed. Open the app once to update this command."

Actual behavior

When the updated app starts, nothing rewrites the launcher, so it still names the deleted AppImage. Only Settings › t3 command › uninstall, then install, fixes it.

DesktopCliShim.install has two callers: DesktopCliCommand.install (the Settings button) and buildWindowsPrimaryConfig (DesktopBackendConfiguration.ts#L786 on main). Nothing calls it at startup on Linux or macOS. With Local environment off, no primary backend config is built at all, so a call there would not run in client mode either.

My desktop trace has no desktop.cliShim.install span when the updated 0.1.7 app started (14:00:15 UTC). "installed t3 launcher" first appears at 14:03:33, after uninstall and install in Settings.

Related, but for the runtime launcher after a server self-update rather than the AppImage launcher: #25724, #14609.

Impact

Minor bug or occasional failure

Version or commit

0.1.7 (stable, AppImage); same callers on main 337c585

Environment

Ubuntu 24.04.5, GNOME on X11, AppImage, Local environment off, paired with the background service on the same machine

Logs or stack traces

# desktop.trace.ndjson
14:00:15.072 desktop.bootstrap   # updated app (0.1.7) starts; no desktop.cliShim.install span follows
14:03:32     desktop.cliCommand.uninstall
14:03:33     desktop.cliShim.install  "installed t3 launcher"

Workaround

After each update, uninstall and reinstall the t3 command from Settings, or rewrite the app= line in ~/.t3/bin/t3 to the new AppImage path.

Activity

  1. shivamhwp commented on Nov 5, 2026

    @shivamhwp
    Collaborator

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

    Independently reproduced on corex's Linux desktop with an AppImage built from main 337c5858c33bc7f8f6dfd391a2c279fa0f7e4d17 using vp run build:desktop and scripts/build-desktop-artifact.ts --platform linux --target AppImage --arch x64 --skip-build. In an isolated HOME, I seeded an app-marked launcher naming an absent previous AppImage and started the current image with Local environment disabled. After the window opened, t3 --version still exited 127 and the launcher still named the old image. The desktop trace confirmed the client-only bootstrap branch ran.

    The native local-backend configuration already refreshes the shim; client-only startup skips it. Julius's #31522 now owns this fix, so I stopped the duplicate work. I have not tested that PR's head or native macOS/Windows behavior.

    The capture shows the isolated desktop and the CLI result after startup:

    Client-only startup leaves the launcher pointing at the absent old AppImage

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

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions