Linux: "Default App" / "$EDITOR" file-link editor setting opens the system browser instead of an editor

Pre-submit Checks

• I have searched Warp bugs and there are no duplicates
• I have searched Warp known issues page and my issue is not there
• I have an issue with AI and have included the debugging ID
• I have technical issue and have included the logs

Describe the bug

On Linux, Settings → Editor and Code Review → "Choose an editor to open file links" doesn't reliably open the selected editor. With Default App selected (and, less directly, with $EDITOR selected), clicking a file link in the terminal instead opens the file in the system's default web browser (in my case, Zen).

Root cause (traced in the current master source)

open_file_path_with_line_and_col in app/src/util/file/external_editor/linux.rs:

pub fn open_file_path_with_line_and_col(..., with_editor: Option<Editor>, full_path: &Path, ctx: &mut AppContext) {
    if full_path.is_file() {
        let with_editor = with_editor.or_else(|| get_app_for_file_from_mime(full_path));
        if let Some(editor) = with_editor
            && let Some(mut command) = editor.command(full_path, line_column_number)
        {
            // ... spawn and return
        }
    }
    ctx.open_file_path(full_path); // <-- unconditional fallback
}

• For EditorChoice::SystemDefault ("Default App"), open_file_path_in_external_editor (in mod.rs) passes editor: None. get_app_for_file_from_mime then shells out to xdg-mime query filetype + xdg-mime query default, but only recognizes a fixed list of ~25 hardcoded IDE app-ids (Editor::app_ids() — VSCode, JetBrains family, Sublime, Zed, Windsurf). On my system the mime default for a .py file is nvim.desktop, which isn't in that list, so with_editor stays None.
• Because nothing matched, execution falls straight through to ctx.open_file_path(full_path), which on Linux (crates/warpui/src/windowing/winit/delegate.rs) is just:

  let _ = command::blocking::Command::new("xdg-open").arg(path).spawn();
  

• Bare xdg-open <path> on a system whose desktop-environment isn't one xdg-utils recognizes (I'm on Omarchy, an Arch/Hyprland-based distro; $XDG_CURRENT_DESKTOP doesn't match xdg-open's built-in DE branches) falls through to its own last-resort fallback of opening the argument in the default web browser — which is exactly the symptom observed. I confirmed xdg-settings get default-web-browser on my machine returns zen.desktop, matching what actually opens.
• The same fallthrough is hit for EditorChoice::EnvEditor ("$EDITOR") whenever the terminal session's $EDITOR isn't captured by Warp (workspace/view.rs's FileTarget::EnvEditor arm calls the same open_file_path_in_external_editor with editor: None in that case).

So the underlying issue is that the final fallback trusts xdg-open's own desktop-environment detection, which isn't reliable on non-mainstream Linux setups, and Warp has no deterministic fallback of its own for mime-default apps outside the hardcoded editor list.

(Separately, and less confidently traced: I also saw the VSCode option in that same dropdown fail to open VSCode and fall back to the browser too, even though code-url-handler.desktop and /usr/bin/code are correctly registered on my system. That path goes through Editor::command()'s VSCode => Command::new("xdg-open").arg("vscode://file...") branch, so if it really is affected, the same DE-detection issue in xdg-open would be the suspect — but I couldn't fully confirm this second symptom without a live repro session, so treat it as a secondary, unconfirmed data point rather than part of the traced bug above.)

To reproduce

1. On Linux, with a desktop environment xdg-open's DE detection doesn't specifically recognize (e.g. a Hyprland-based distro like Omarchy — $XDG_CURRENT_DESKTOP unset or non-standard), set a browser as the system default browser (xdg-settings set default-web-browser <browser>.desktop).
2. In Warp, go to Settings → Editor and Code Review → "Choose an editor to open file links" → select Default App.
3. In a terminal pane, run a command that prints a clickable file path (e.g. a Python traceback, or just ls -la some/existing/file.py).
4. Ctrl/Cmd-click the file path.

Expected behavior

The file opens in the system's actual mime-type default application (or fails clearly), not in the default web browser.

Screenshots, videos, and logs

The xdg-mime/xdg-settings output I used to trace the root cause is described inline above. I can attach a screen recording if useful, but the code trace above should be reproducible by reading the linked source directly.

Operating system (OS)

Linux

Operating system and version

Omarchy (Arch Linux, Hyprland-based) — kernel 7.2.5-3-omarchy

Shell Version

zsh

Current Warp version

Oz v0.2026.09.09.08.26.stable_02 (from warp-terminal --version)

Regression?

No, this bug or issue has existed throughout my experience using Warp.

Additional context

Using Wayland (Hyprland). I have a fix in progress that resolves the mime-type default app directly from its .desktop entry (reusing the EditorMetadata/Exec-tokenizing code already used for the hardcoded editor list) instead of deferring to bare xdg-open, only falling back to ctx.open_file_path when no .desktop entry can be resolved at all. I'll open a PR linked to this issue.

Does this block you from using Warp daily?

No

Is this an issue only in Warp?

Yes, I confirmed that this only happens in Warp, not other terminals.