fix(desktop): Stop hiding an installed Linux launcher with the URL handler entry - #31405

Approvability

Verdict: Needs Human Approval

Macroscope's review found this PR requires human approval — The change prevents generated URL-handler entries from hiding installed Linux launchers. Cleanup can also delete customized entries and lose user Exec overrides; preservation of those customizations needs resolution.

Needs human approval because:

• 1 blocking correctness issue found at or above your repo's Minimum Blocking Severity

^{Adjust the Minimum Blocking Severity for this repo — including turning it Off — in Settings. You can add or adjust custom eligibility rules. Learn more.}

No actionable comments were generated in the recent review.

Merge Risk: Minimal · up to 85105

This change stops a hidden URL-handler entry from hiding an installed Linux launcher, and it preserves entries the user created. No concrete failure was established. One reported edge case remains unverified: a Nix profile whose desktop database is not updated might not dispatch the SSO redirect after the generated entry is removed. Packaged and real-desktop behavior were not tested, so check that case if it matters to you.

Pre-merge checks: 4

Check name	Status	Explanation
Title check		The title names the main change: the URL handler entry should no longer hide an installed Linux launcher. It follows the conventional commit format and matches the changes to the desktop writers and t…
Linked Issues check		Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check		Check skipped because no linked issues were found for this pull request.
Description check		The description follows the repository template closely. It has all four required sections: Problem, Change, Scope, and Verification. The Problem section states the expected behavior and the environme…

Full details: Title check

Explanation

The title names the main change: the URL handler entry should no longer hide an installed Linux launcher. It follows the conventional commit format and matches the changes to the desktop writers and the XDG_DATA_DIRS check.

Full details: Description check

Explanation

The description follows the repository template closely. It has all four required sections: Problem, Change, Scope, and Verification. The Problem section states the expected behavior and the environment, which is NixOS with XDG_DATA_DIRS. The Change section explains the fix and why the rest of registration is unchanged. The Scope section explains why this is a bug fix, links the related issue, and states that a maintainer decision on the .deb rename is out of scope. The Verification section lists focused unit tests with results, an end-to-end run on NixOS, and items that were not checked. The description has one small gap. The Problem section links a PR comment and #32482, but it does not link the issue that shows the bug directly. The Scope section does say that the author linked the earlier triage, so the gap is minor. The description also ends with a model and harness attribution, which the template asks for.

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Recent review info

Run configuration

• Source mode: Auto
• Repository: pingdotgg/t3code
• Branch: main
• File: .coderabbit.config.ts
• Commit: 48cdefe
• Layers: Repository TS config
• Review profile: CHILL
• Plan: Advanced
• Run ID: e6692724-ff86-4970-960a-27863bb539e3

Commits

Reviewing files that changed from the base of the PR and between 0fa11d7 and 85105e0.

Files selected for processing: 4

• apps/desktop/src/app/DesktopLinuxUrlHandler.test.ts
• apps/desktop/src/app/DesktopLinuxUrlHandler.ts
• apps/desktop/src/app/DesktopPreReadyPlatform.test.ts
• apps/desktop/src/app/DesktopPreReadyPlatform.ts

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 9 remain after this review.

Verified in a real dev environment

Head 0fa11d7543de against main d2c25950b4, Ubuntu VM with Xorg. Each worktree ran vp run dev:desktop (dev entry id com.t3tools.T3Code.Development.desktop) with XDG_DATA_HOME and XDG_DATA_DIRS pointed at throwaway dirs. The "installed launcher" is a visible entry with that id in $XDG_DATA_DIRS/applications, Categories=Development; and MimeType=x-scheme-handler/t3code-dev;. After each launch I checked the $XDG_DATA_HOME entry and asked GIO (Gio.DesktopAppInfo.new(id), the lookup desktop shells use) which file the id resolves to.

PR launch B transcript:

=== B: installed launcher in $XDG_DATA_DIRS + generated entry left by launch A (0fa11d7543)
before launch:
-rw-rw-r-- 1 user user 260 14:29:45 /tmp/xdg-pr/home/applications/com.t3tools.T3Code.Development.desktop
--- $XDG_DATA_HOME/applications/com.t3tools.T3Code.Development.desktop:
(absent)
--- GIO lookup of com.t3tools.T3Code.Development.desktop:
resolves to: /tmp/xdg-pr/sys/applications/com.t3tools.T3Code.Development.desktop
shown in menus: True
default for x-scheme-handler/t3code-dev: com.t3tools.T3Code.Development.desktop

Same launch on main: the entry's mtime moved to the launch time, and GIO resolved the id to /tmp/xdg-main/home/applications/... with shown in menus: False.

Nearby behavior: with the installed launcher present and no hidden entry, the PR's desktop window started normally. In that window I added a local git repo as a project, picked Claude Haiku 5.5, and ran a real turn. It finished in 6.2s with the correct answer. The hidden entry was still absent after the runtime URL handler registration and the turn.

Not verified

• Packaged builds (.deb, AppImage, AUR). The xdg-mime default and icon steps only run when packaged, so the dev launches skipped them.
• Deep links opened through the installed launcher, and how a real desktop shell menu displays the result. Menu visibility was checked through GIO only.
• Production id com.t3tools.T3Code.desktop. The dev launches use the .Development id through the same code path.

This PR conflicts with main. Rebase it or merge main into it. If it still conflicts after 7 days with no activity, it will be closed automatically.

See the conflict window.

Before writing the handler entry, both writers (DesktopPreReadyPlatform and DesktopLinuxUrlHandler) check whether $XDG_DATA_DIRS (defaulting to /usr/local/share:/usr/share per the XDG Base Directory spec) has an applications/com.t3tools.T3Code.desktop. If it does:

• they skip writing the hidden entry, and

Leaving this here as an edge-case. I install my T3 Code using nix profile install .... It adds a desktop entry to /home/<user>/.nix-profile/share/applications/, but it doesn't update the desktop database for that directory as that's not Nix's responsibility (also, it's readonly). However, because of that, GNOME doesn't recognize that desktop entry as a URL handler, even if xdg-mime default ... is executed. So, to be able to login in T3 Connect via Github SSO, I rely on the hidden entry being written and update-desktop-database being run with it.

I understand nix is not a supported installation method, but I was hoping we could come to a better solution that can accommodate everyone's concerns.

Anyways, the hidden entry was never meant to show up on DE menus. It was initially introduced for the specific purpose of allowing the redirect of Github SSO in T3 Connect to be captured by T3 Code, hence why it has NoDisplay=true, and no Categories.

Based on this, wouldn't the better solution be something like: com.t3tools.T3Code.desktop only written if there's not one in $XDG_DATA_DIRS, and then com.t3tools.T3Code-redirect.desktop to capture the redirect, always written?

This is something I just came up with and haven't given much thought, so let me know what you think!

Also, how do other AppImage apps solve this? Do they all write a desktop entry to ~/.local/share/applications/?

@limwa Thanks, I checked this. First, this PR changes nothing for nix-t3code as it is today: it installs t3code.desktop, not com.t3tools.T3Code.desktop, so the hidden entry is still written and update-desktop-database still runs on it.

If a package does install com.t3tools.T3Code.desktop in a read-only directory without a mimeinfo.cache, the scheme should still work. The URL handler registration that DesktopApp starts at every launch (DesktopLinuxUrlHandler.register) only swaps writing the hidden entry for removing it. It then still runs xdg-mime default com.t3tools.T3Code.desktop x-scheme-handler/t3code, as on main. That writes the default to $XDG_CONFIG_HOME/mimeapps.list (xdg-mime). Per the MIME Applications spec, a default resolves to the named desktop file wherever it is installed, provided the entry is associated with the type through its MimeType key. mimeinfo.cache is only an index of those keys.

I checked with GLib 2.90 and xdg-utils, in a clean environment where XDG_DATA_DIRS pointed at a directory containing only applications/com.t3tools.T3Code.desktop (with MimeType=x-scheme-handler/t3code;), and with an empty $XDG_DATA_HOME:

xdg-open t3code://… with XDG_CURRENT_DESKTOP=GNOME also launched it after xdg-mime default. (gio open resolves the handler with g_app_info_get_default_for_uri_scheme.) So the cache only matters when no default is set, and registration always sets one. The xdg-mime step runs only when app.isPackaged is true (the check), which nix-t3code already gets from ELECTRON_FORCE_IS_PACKAGED (here).

On a separate com.t3tools.T3Code-redirect.desktop: it would work, but it would make a hidden entry, rather than the packaged launcher, the scheme handler on every install. It also needs a correct Exec, which the packaged launcher already has.

On AppImages: integration tools (AppImageLauncher, Gear Lever) copy the AppImage’s own desktop entry into ~/.local/share/applications under a name they choose. Without one, the app has to write its own entry, which is why this PR keeps writing the hidden entry whenever no com.t3tools.T3Code.desktop is installed.