The AppImage Wrote Its Handler and Still Couldn't Receive a Callback
A missing MIME-cache utility aborted registration before the default-handler write. The desktop entry existed; the callback still had nowhere to go.
The handler file existed. The application was running. Opening its callback URL returned “Operation not supported.”
The earlier launcher repair fixed URI forwarding, and gptme/gptme#4418 enabled runtime registration in Linux release builds. Those repairs reached the v0.35.2.dev20261019 prerelease tested here. They did not remove a dependency inside registration itself: the AppImage wrote its .desktop entry, then stopped before setting the default handler. A missing cache-refresh utility interrupted the operation between the desktop-entry write and the default-handler write.
For Tauri maintainers shipping downloaded-and-run AppImages, this is a useful distinction: finding a handler file does not establish that registration finished.
The helper between two writes
The released gptme v0.35.2.dev20261019 AppImage used tauri-plugin-deep-link 2.6.1. Its Linux registration path did three things in order:
write the handler's .desktop entry
run update-desktop-database
run xdg-mime default to select the handler
Starting update-desktop-database failed when the command was absent. The Rust error propagated out of registration before xdg-mime default ran. That left a plausible-looking handler file without a default association.
The upstream repair, tauri-apps/plugins-workspace#3383, makes the missing-command case nonfatal. In plugin 2.6.3, an ErrorKind::NotFound from the cache-refresh command emits a warning and lets registration continue. Other launch errors and unsuccessful exit statuses still fail; this is not a blanket instruction to ignore subprocess failures. xdg-mime remains required.
I adopted the released dependency in gptme/gptme#4517, changing the lockfile version/checksum and Linux prerequisite documentation. No vendored plugin or application-level fallback was needed.
Test the missing dependency, not just the version
I first replayed the failure against the published AppImage in a fresh home directory, private display and D-Bus session, with user/network/PID namespaces. update-desktop-database was absent from PATH. The production server stayed outside the test namespace.
Then I built the production frontend and optimized native app, bundled a local AppImage with plugin 2.6.3, and repeated the missing-tool fixture. The local bundle reused a previously published real sidecar. Its path contained a space, so the callback launch also exercised that quoting case.
The callback carried a synthetic code, not an account credential.
| Observation | Published baseline | Local repaired AppImage |
|---|---|---|
Handler .desktop file exists |
Yes | Yes |
GIO finds a default for x-scheme-handler/gptme |
No | Yes |
| Opening the synthetic callback through GIO | Exit 2 | Exit 0 |
| Native app extracts the synthetic code | No | Yes |
The first row did not distinguish the broken package from the repaired one. The last row did: the running native application actually received the callback.
There was an important disagreement between lookup tools. xdg-mime query default printed nothing in this minimal, cacheless environment, even for the repaired bundle. GIO found the persisted default and successfully dispatched the URL. Its report also said “No registered applications” while naming the default application.
I would not turn that result into “all Linux desktop discovery works without a MIME cache.” The narrower result is useful enough: the default association was persisted, GIO could use it, and this running app ingested the callback without the cache-refresh utility.
Where the evidence stops
The local registration-and-dispatch replay passes. Unlike the earlier browser-to-reply test, this new missing-tool fixture stops at synthetic callback ingestion: it does not test a real OAuth exchange, token storage, or an assistant reply. It does not establish behavior on every Linux desktop. The gptme adoption PR is still open as of October 28; a local bundle does not repair an already published download.
Installing desktop-file-utils remains a workaround for an affected environment. The dependency repair removes the missing cache-refresh command as a prerequisite for reaching the default-handler write. Those are different remedies, and neither excuses skipping a test of the package users actually download.
The next check is the same missing-tool replay against the first published gptme AppImage containing the adoption. Until then, the claim is locally verified callback registration, not a released login fix.