`flatpak run dev.zed.Zed` opens additional tabs

[A2va]

When doing flatpak run dev.zed.Zed some_file.txt, zed opens the file with two additional tabs that are named --zed and zed-editor.

[musaad-sharikh]

Confirming this on v1.10.3 — and it has a worse consequence than the extra tabs: the phantom entries are persisted in the workspace database and break session restore.

Same two bogus entries (--zed and the zed-editor binary) as in the original report, but they aren't only cosmetic tabs — they're stored as project worktrees, and on the next launch they make restore_on_startup: "last_session" fail, so Zed reopens with a blank window instead of the previous project and tabs.

Environment

• Zed v1.10.3 (Flatpak, origin flathub, commit f570d1a8…)
• Fedora 44, Wayland (niri compositor)

What gets injected

Opening any path adds two spurious project folders to that workspace (cwd was /home/mbm):

/home/mbm/--zed
/var/lib/flatpak/app/dev.zed.Zed/x86_64/stable/<hash>/files/libexec/zed-editor

--zed is the literal flag resolved as a relative path; the second is the editor binary itself. Both the default zed-wrapper entrypoint and --command=zed are affected.

Why it breaks session restore

On the next launch, last_session restore tries to reopen that workspace and chokes on the binary path:

WARN [workspace] Failed to open a project item: opening project path
".../files/libexec/zed-editor": Binary files are not supported

Restoring that workspace aborts and Zed opens an empty window instead. Restore itself is not broken — a workspace without the phantom paths restores correctly across quit/relaunch.

Steps to reproduce

1. flatpak run dev.zed.Zed /path/to/project /path/to/project/file.txt
2. Observe the two extra --zed and zed-editor folders/tabs in the project panel.
3. Fully quit Zed.
4. Relaunch with no arguments (flatpak run dev.zed.Zed), with "restore_on_startup": "last_session".

Observed: blank window; the project and its tabs are not restored.
Expected: the previous project and open tabs are restored.

Where it persists

Written into ~/.var/app/dev.zed.Zed/data/zed/db/0-stable/db.sqlite, so it survives quits:

• workspaces.paths / workspaces.identity_paths — the two paths as project worktrees
• editors + items — --zed as an open tab
• trusted_worktrees — the phantom paths marked trusted
• scoped_kv_store → multi_workspace_state — per-window state embeds them

Root-cause pointer

The Flatpak CLI (/app/bin/zed) exits the sandbox and re-execs the editor on the host via flatpak-spawn --host; the internal --zed <editor-binary> used for that re-exec appears to be forwarded as paths-to-open. Setting ZED_FLATPAK_NO_ESCAPE=1 (which skips the sandbox escape) makes the phantom entries disappear entirely, which points at the escape/re-exec path as where the arguments leak in.

Note

Launching with no file/folder argument does not trigger this — only opening a path does. A cold start that merely restores an already-clean session therefore looks fine, which can mask the bug.

I can share sanitized DB rows or full logs if that's helpful.

[mlech-reef]

I can confirm this. Also Fedora 44, Wayland (niri compositor)

[jonaslb]

Seems zed-industries/zed#57440 introduced this by putting #[arg(trailing_var_arg = true, value_hint = clap::ValueHint::AnyPath)] on paths_with_position.

The problem is that Zed's Flatpak launcher puts arguments after any paths passed to zed. However that behaviour is much older than the above change. But those arguments are now interpreted as paths due to that.

[maciej-lech]

@jonaslb so this is a bug in Zed (a regression): https://github.com/zed-industries/zed/blob/55ea5baf15027d185390e8aa1b6b7768cc059330/crates/cli/src/main.rs#L1075