Remote transport for Flatpak host

[blue42u]

Body

What are you proposing?

A new option to "remote" into the host system via flatpak-spawn --host and zed-server. This command can be used whenever Zed is running inside a Flatpak sandbox (i.e. when ZED_FLATPAK_NO_ESCAPE=1 is set), and would be suggested as a toast when opening a project.

Why does this matter?

The only available support for Flatpak re-spawns the entire editor on the host system (so-called "escape mode"). This approach causes crashes when host processes are involved, including:

• Terminal not working correctly on linux/flatpak #53129
• Unable to run podman (libbsd not found) flathub/dev.zed.Zed#224
• Leaks LD_LIBRARY_PATH into application - including zed terminals flathub/dev.zed.Zed#330
• libselinux.so.1: no version information available (required by sed) flathub/dev.zed.Zed#334
• "No such file or directory" on musl libc Linux distributions when escaping the Flatpak sandbox flathub/dev.zed.Zed#3

Those who worked around the above issues disabled the Flatpak escape (so-called "sandbox mode"), leading to a different set of issues:

• Agent Servers don't work with custom terminal shell #47991
• Environment variable loading is broken in sandboxed Flatpak mode when Nushell is the default shell #43410
• flatpak-spawn --host and tcsetpgrp issue flatpak/flatpak#3697 (when using flatpak-spawn as the terminal shell)
• Devcontainers are unusable in sandboxed mode flathub/dev.zed.Zed#336
• GPG failed to sign commit with sandbox flathub/dev.zed.Zed#347
• Secrets integration doesn't work with sandbox flathub/dev.zed.Zed#350
• Zed without sandbox doesn't open addresses in browser flathub/dev.zed.Zed#351
• Add support for Devcontainers in sandbox mode flathub/dev.zed.Zed#342

As a result of the poor experience both ways, the community-led Flathub package has "waffled" between disabling the sandbox escape (flathub/dev.zed.Zed#275) and ultimately reverting that change (flathub/dev.zed.Zed#352). Neither approach is making everyone happy.

The Flathub package gets 10,000+ downloads a month, with over 200,000 total installs. These many users of Zed would benefit greatly from a smoother Flatpak experience than upstream Zed currently provides.

Are there any examples or context?

• Ptyxis (terminal emulator) runs shells on the host via an out-of-sandbox ptyxis-agent
• Ghostty (terminal emulator) has built-in Flatpak support alongside a lengthy discussion of various related details

The approach suggested below builds on the recently added Dev Containers support, which uses zed-server to access a "remote" container environment much like the already proven ptyxis-agent approach. This avoids the invasive changes previously proposed for Flatpak support in #11949.

Possible approach

(I don't claim to know anything about the Zed codebase, but my idea is:)

The RemoteConnection architecture can be extended to support this use case, using the same structure as DockerExecConnection (Dev Container support). In this scenario the zed-server runs on the "remote" (host) system and provides access to the host development environment:

       Sandbox           ~ ~ ~                  Host
                         ~ ~ ~
Zed editor ---> (flatpak-spawn --host) ---> (zed-server) ---> LSPs, tools, terminals, etc.
                         ~ ~ ~

This is structurally very similar to the Docker transport, the main difference being the wrapper command (flatpak-spawn --host ... instead of docker exec ...). For further simplicity, the zed-server binary can be bundled in the Flatpak and executed via its host-side path, using the same flatpak::get_flatpak_dir() used for the "escape" code today.

Additional notes

• No code changes are needed to enable Dev Container support while the editor is sandboxed, it only requires docker/podman CLIs and sockets inside the Flatpak sandbox. See Add support for Devcontainers in sandbox mode flathub/dev.zed.Zed#342 for an implementation.

• There is potential synergy with devcontainers: run git on the host #54613: if "Git on host" is enabled, git (and other core CLIs) can be installed/used inside the Flatpak sandbox even on systems where these tools are unavailable (or broken/old) on the host. This would be especially handy for end-user-oriented distros or where package installs are difficult (e.g. atomic OSs and managed systems), as a lightweight alternative to a full Dev Container setup.