JetBrains Gateway does not open (AppImage builds only)

[keturn]

What happened?

Starting a Workspace with the WebStorm IDE, it proceeds without error but Gateway doesn't open and connect.

Looking at active processes, I can see that devpod-cli did run /usr/bin/sh /usr/bin/xdg-open jetbrains-gateway://connect#idePath=… which in turn opened chrome with that URL.

This seems like a desktop configuration issue, but the thing that has me puzzled is if I copy-and-paste that URL out of the process info and use it with xdg-open from a terminal, it does load Gateway as expected.

Local Environment:

• DevPod Version: v0.8.1
• Operating System: linux (Ubuntu 25.04)
• ARCH of the OS: AMD64

DevPod Provider:

• Local/remote provider: docker (podman)

Anything else we need to know?

I have run xdg-desktop-menu forceupdate. I also logged out of the desktop session entirely and logged in again but that didn't seem to make any more difference.

[keturn]

On a different Ubuntu system (25.10), using the ssh provider, it worked just fine.

[skevetter]

Do you see any error messages being displayed? If so, any logs you can provide would be much appreciated. Opened PR #128

Linking cross-repo related issues for context

• Can’t use Intellij as IDE loft-sh/devpod#1047
• "<external command>": executable file not found in $PATH, out: `` in the UI loft-sh/devpod#1250

[keturn]

Nope, no errors, as Gateway is installed (unlike the original error in 1047) and xdg-open does run without complaint. It's just opened the wrong thing.

[skevetter]

Any chance you could try out the build artifacts from the PR in case this fixes it for you?

https://github.com/skevetter/devpod/actions/runs/20293402024?pr=128

[skevetter]

FYI, if this PR #128 doesn't fix the opening with browser.OpenURL, I'll swap the ordering around to use xdg-open as the primary instead of the fallback. Although that should not be necessary since that's exactly what this pkg/browser library that I added does.

[keturn]

Wow, there is some deep gnome/appimage mischief going on here.

I added some tracing to xdg-open and discovered the traces diverge when it tests for gio help open. Normally, that succeeds, but when run as a child of the appimage process, the system gio links against the image's glib and it falls over with this error:

gio: symbol lookup error: gio: undefined symbol: g_unix_mount_entry_get_options

And then whatever fallback path it uses does figure out the URL is associated with the desktop entry for Gateway, but ultimately fails to execute on it, perhaps for similar reasons.

I guess people have been running in to this for a while: AppImage/AppImageKit#396

So one option is Don't Use Appimage.

I did a little more digging, and it looks like the answer for dbus-loving desktop environments is to use the portal.OpenURI interface: https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.OpenURI.html#org-freedesktop-portal-openuri-openuri

[skevetter]

To confirm, the latest build artifact desktop app did not work for you? It should be calling xdg-open. If not, I'll have to dig into this more.

https://github.com/skevetter/devpod/actions/runs/20357091508/artifacts/4919535927

[keturn]

It calls xdg-open both in that build and in main. The problem is that xdg-open does not work reliably when executed within the AppImage. (At least with the current AppImage on a Ubuntu 25.04 desktop.)

The deb works fine, which is great but for the fact that the install docs on the main site encourage AppImage instead of deb.

[skevetter]

xdg-open does not work reliably

I see. I will need to dig deeper to see if there are any workarounds. For the moment, I suppose you will have to rely on the deb package unless you know of a fix.

As for the documentation, I would like to (eventually) host my own netflify domain to keep the docs up-to-date. For the moment, somone facing the same issue will hopefully find their way here.

[skevetter]

I noticed this the other day

devpod/.github/actions/create-linux-release-artifacts/action.yml

Line 40 in 7430cfb

tar --exclude=usr/bin/xdg-open --exclude=usr/lib --exclude=usr/share/doc --exclude=usr/share/glib-2.0 -zcvf DevPod-desktop.tar.gz usr

I need to investigate if this issue is a build issue that can be fixed as part of the workflow or something else.