Skip to content

Toolport v1.16.0

Choose a tag to compare

View all tags
@github-actions github-actions released this 22 Aug 19:26
· 118 commits to main since this release
v1.16.0
d0f343d

One Linux download that works on every GPU

Toolport's AppImage opened a grey, empty window on Arch, Omarchy, Manjaro and other rolling distros — but only on Mesa, which is to say AMD and Intel graphics. NVIDIA machines were fine. That split made it look like an AMD bug, and 1.15.0 shipped advice to install a native package instead and pick your download by driver.

It was never about the GPU. 1.16.0 fixes it at the source: one AppImage, running on Omarchy, Arch, Manjaro and EndeavourOS across AMD, Intel and NVIDIA alike. No native package required, no driver-specific advice, nothing to choose.

scripts/install.sh follows suit — Arch just gets the AppImage now. toolport-bin is still published for anyone who would rather have a real package that upgrades through pacman; it's a preference now, not a workaround.

What was actually wrong

The AppImage bundled wayland 1.20. AppRun puts the bundle on LD_LIBRARY_PATH, and the dynamic loader applies that to everything the process opens afterwards — including the host's GPU drivers, which are deliberately not bundled. So the host's own Mesa was resolved against a four-year-old wayland:

/usr/lib/libEGL_mesa.so.0: undefined symbol: wl_fixes_interface

wl_fixes_interface arrived in wayland 1.23. libEGL_mesa therefore never loaded at all, eglGetDisplay returned nothing, and WebKitWebProcess aborted on startup with EGL_BAD_PARAMETER — a window that opens and never paints. NVIDIA's proprietary EGL doesn't link libwayland-client, which is the only reason it escaped.

Earlier releases blamed the bundled WebKitGTK for this. That was wrong — it's current (2.50.4) and was never involved. The AppImage simply stops shipping the wayland libraries, so the host's own are used, and the build fails loudly if any ever sneak back in.

Sign-in on Linux opens the browser again

The same environment leak, pointed outward. Every process Toolport spawned inherited the bundle's library paths, so a host binary loaded Ubuntu 22.04's glib or brotli instead of the system's and died at link time before running any of its own code:

chromium: symbol lookup error: undefined symbol: BrotliDecoderAttachDictionary

In practice: clicking Authenticate on an OAuth server said "opening browser" and nothing happened, ever. The same hazard was latent on any MCP server that is a native binary or pulls a native node/python module — the app's core function, not a cosmetic path.

Anything Toolport launches that isn't its own bundled payload now gets the host's environment: the browser, MCP servers, the file manager, your login shell. Your PATH, HOME, proxy variables and each server's own env block are left exactly as they were.

Also in this release

  • Windows: launch at login no longer reports "Off" when it's on. The status now reads the registry Run entry and its startup-approval state byte instead of a timestamp heuristic. (#830)
  • The HTTP/OpenAPI endpoint survives a restart. Enablement and port persist, and the bearer token is reused from the OS keychain instead of rotating on every launch, so a client configured against it keeps working. (#829)
  • OpenCode opencode.jsonc configs are detected. Reads, writes, gateway install and launch migration share one path picker that prefers an existing .jsonc and preserves its comments and trailing commas. (#827)
  • Adding a server whose secret failed to save no longer leaves you with a duplicate. (#826)

Thanks

  • @rohankumardubey — a partial server add used to strand you: if a secret write failed after the server was created, retrying made a second server. Now every write is attempted, the failed keys are named, and the dialog stays open in edit mode so the retry updates the server you just added. (#826)

Thank you for keeping at these. It's the kind of fix that only turns up from real use.

Install

# macOS or Linux
curl -fsSL https://toolport.app/install.sh | bash

# macOS (Homebrew)
brew install --cask tsouth89/toolport/toolport
# Windows
irm https://toolport.app/install.ps1 | iex

On Linux, take the .deb on Debian/Ubuntu and the AppImage everywhere else. Installed copies from 0.3.3+ update themselves.

If you worked around the grey window with the native package, you can stay there — nothing is broken. You just don't have to any more.

Full changelog: https://github.com/tsouth89/toolport/blob/v1.16.0/CHANGELOG.md

Assets 15
Loading