Zed without sandbox doesn't open addresses in browser

[mati865]

EDIT: As the workaround I'm doing rm -r ~/.local/share/flatpak/app/dev.zed.Zed/current/active/files/lib/* after each update and it seems to work fine.

Original report below:

Zed ships libraries that are conflicting with ones provided by freedesktop-sdk-25.08.8 (likely other versions too). See individual cases:

Sandbox Enabled

With default configuration (sandbox enabled) clicking on "Sign In" button in the top right-hand corner opens a new tab in my browser, despite some tools failing to launch due to messed up dependencies:

❯ flatpak run dev.zed.Zed --foreground
2026-04-16T17:51:50+02:00 INFO  [zed] ========== starting zed version 0.232.2+stable.229.34f1025a77a17ae5401c9395b4f73536c6f76d6c, sha 34f1025 ==========
<snip>
2026-04-16T17:51:53+02:00 INFO  [client] set status on client 0: Authenticating
2026-04-16T17:51:53+02:00 ERROR [crates/client/src/client.rs:369] File backend error Portal communication failed A portal frontend implementing `org.freedesktop.portal.Secret` was not found
/usr/lib/x86_64-linux-gnu/gio/modules/libgiognomeproxy.so: undefined symbol: g_uri_is_valid
Failed to load module: /usr/lib/x86_64-linux-gnu/gio/modules/libgiognomeproxy.so
/usr/lib/x86_64-linux-gnu/gio/modules/libgiognutls.so: undefined symbol: g_source_set_static_name
Failed to load module: /usr/lib/x86_64-linux-gnu/gio/modules/libgiognutls.so
/usr/lib/x86_64-linux-gnu/libproxy/libpxbackend-1.0.so: undefined symbol: g_strv_builder_unref
Failed to load module: /usr/lib/x86_64-linux-gnu/gio/modules/libgiolibproxy.so

The secrets are not stored though, as reported in #350.
Trying to launch secret-tool also fails:

❯ flatpak run --command=sh dev.zed.Zed
[📦 dev.zed.Zed dev.zed.Zed]$ secret-tool
secret-tool: symbol lookup error: /usr/lib/x86_64-linux-gnu/libsecret-1.so.0: undefined symbol: g_task_set_static_name

Sandbox Disabled

Without sandbox clicking on "Sign In" button doesn't do anything as some binary fails to start:

❯ flatpak run dev.zed.Zed --foreground
2026-04-16T17:56:17+02:00 INFO  [zed] ========== starting zed version 0.232.2+stable.229.34f1025a77a17ae5401c9395b4f73536c6f76d6c, sha 34f1025 ==========
<snip>
2026-04-16T17:56:19+02:00 INFO  [client] set status on client 0: Authenticating
XPCOMGlueLoad error for file /usr/lib/firefox/libmozgtk.so:
/usr/lib/libjson-glib-1.0.so.0: undefined symbol: g_once_init_leave_pointer
Couldn't load XPCOM.

secret-tool fails the same way.

Sandbox Disabled and Conflicting Deps Removed

I have pinpointed shipped libs that conflict with the platform version 49 and removing them fixes the issue:

❯ cd /home/mateusz/.local/share/flatpak/app/dev.zed.Zed/current/active/files/lib/
❯ mkdir bck
❯ mv libglib-2.0.so.0 libgio-2.0.so.0 libmount.so.1 libgmodule-2.0.so.0 bck/

Now when I click on "Sign In" the new tab in my browser is opened and secrets are stored. They are correctly restored when relaunching Zed.
Also secret-tool works fine now:

❯ flatpak run --command=sh dev.zed.Zed
[📦 dev.zed.Zed dev.zed.Zed]$ secret-tool
usage: secret-tool store --label='label' attribute value ...
       secret-tool lookup attribute value ...
       secret-tool clear attribute value ...
       secret-tool search [--all] [--unlock] attribute value ...
       secret-tool lock --collection='collection'

Related issues #330 #334

[yeskunall]

Hey @mati865 -- thanks for reporting this here. Not too familiar with Flathub, so I have to ask: is this something Flathub has to fix? It doesn’t sound like it judging from your findings above, but if you or someone else has a better understanding of this problem, I’d love to know how we can fix things on our end (if at all).

[mati865]

@yeskunall I have little experience with flatpak packaging, so I cannot suggest the best action here. I think the problem is repacking too many or too few libraries provided in Zed packages. IMO the package ideally would be built from source, rather than repacked to avoid any incompatibilities.

[proletarius101]

Hey @mati865 -- thanks for reporting this here. Not too familiar with Flathub, so I have to ask: is this something Flathub has to fix? It doesn’t sound like it judging from your findings above, but if you or someone else has a better understanding of this problem, I’d love to know how we can fix things on our end (if at all).

It seems like something Zed has to change. In general, Zed would be more compatible with Linux and Flatpak if it used XDG Desktop Portal documentation to open a link and access the system APIs.

There are convenience libraries to help you to integrate.

[mati865]

xdg-open opens the url, but similarly to many other tools in recent Zed flatpaks something fails to launch:

❯ flatpak run --command="xdg-open" dev.zed.Zed -- http://localhost
/usr/lib/x86_64-linux-gnu/gio/modules/libgiognomeproxy.so: undefined symbol: g_uri_is_valid
Failed to load module: /usr/lib/x86_64-linux-gnu/gio/modules/libgiognomeproxy.so
/usr/lib/x86_64-linux-gnu/gio/modules/libgiognutls.so: undefined symbol: g_source_set_static_name
Failed to load module: /usr/lib/x86_64-linux-gnu/gio/modules/libgiognutls.so
/usr/lib/x86_64-linux-gnu/libproxy/libpxbackend-1.0.so: undefined symbol: g_strv_builder_unref
Failed to load module: /usr/lib/x86_64-linux-gnu/gio/modules/libgiolibproxy.so

I guess its main code path failed because of the conflicting libs, but used some kind of fallback.

[proletarius101]

xdg-open opens the url, but similarly to many other tools in recent Zed flatpaks something fails to launch:

❯ flatpak run --command="xdg-open" dev.zed.Zed -- http://localhost
/usr/lib/x86_64-linux-gnu/gio/modules/libgiognomeproxy.so: undefined symbol: g_uri_is_valid
Failed to load module: /usr/lib/x86_64-linux-gnu/gio/modules/libgiognomeproxy.so
/usr/lib/x86_64-linux-gnu/gio/modules/libgiognutls.so: undefined symbol: g_source_set_static_name
Failed to load module: /usr/lib/x86_64-linux-gnu/gio/modules/libgiognutls.so
/usr/lib/x86_64-linux-gnu/libproxy/libpxbackend-1.0.so: undefined symbol: g_strv_builder_unref
Failed to load module: /usr/lib/x86_64-linux-gnu/gio/modules/libgiolibproxy.so

I guess its main code path failed because of the conflicting libs, but used some kind of fallback.

Yes. I'd suggest to delete those packaged libraries and rely on the ones in the Flatpak runtime. Or clear LD_PRELOAD to ignore the packaged ones. Of course, ideally, if Zed is compiled with the Flatpak runtime in this distribution, that error won't happen in the first place.

[hdm-benni]

I have pinpointed shipped libs that conflict with the platform version 49 and removing them fixes the issue:

❯ cd /home/mateusz/.local/share/flatpak/app/dev.zed.Zed/current/active/files/lib/
❯ mkdir bck
❯ mv libglib-2.0.so.0 libgio-2.0.so.0 libmount.so.1 libgmodule-2.0.so.0 bck/

Can confirm this fixes the issue

[mati865]

I've made an attempt to properly build Zed rather than repacking and the obstacle I see so far is the disabled network access during the build. Since Zed doesn't provide tarballs that contain vendored dependencies (or I couldn't find one), it would require using flatpak-cargo-generator.py like described here: https://github.com/flathub/org.metamuffin.hurrycurry.client/blob/96298e3ce825d21d0be0699cb19abd07d5396870/readme.md#building

This would add much more maintenance work, which might be not welcome by the maintainers.

[mati865]

Updated the report with workaround that I apply after the updates.