Odd behavior of write_screen_file:open when opening Zig output

[0x4a61636f62]

Issue

I have set Neovim as my default application for opening text files. Regardless of the output, my keyboard shortcut (keybind = ctrl+shift+h=write_screen_file:open) opens the file in Neovim, as expected.

Except when the output is from a Zig command, such as zig build test, the file opens in my Brave browser instead. This behavior is unexpected and incorrect (Brave is not even my default browser by the way).

Examples

Expected Behavior:

The following works correctly and opens in Neovim:

[redacted][~//Coding/zig/fsm][main ?!] → ghostty --version
Ghostty 1.0.1

Version
  - version: 1.0.1
  - channel: stable
Build Config
  - Zig version: 0.13.0
  - build mode : builtin.OptimizeMode.ReleaseFast
  - app runtime: apprt.Runtime.gtk
  - font engine: font.main.Backend.fontconfig_freetype
  - renderer   : renderer.OpenGL
  - libxev     : main.Backend.io_uring
  - GTK version:
    build      : 4.16.12
    runtime    : 4.16.3
  - libadwaita : enabled
    build      : 1.6.2
    runtime    : 1.6.1
  - libX11     : enabled
  ........
[redacted][~//Coding/zig/fsm][main ?!] → 

Unexpected Behavior:

The following opens in Brave browser instead of Neovim:

[redacted][~//Coding/zig/my_special_project][main ?!] → zig build test
test
└─ run tests
   └─ zig test tests Debug native 1 errors
src/tests.zig:43:31: error: expected type '*main.StateMachineBuilder(tests.State,tests.Input,&.{ .{ ... }, .{ ... } }[0..2],.Idle,(function 'dummyStartFn'),(function 'dummyEndFn'),(function 'dummyErrFn'))', found '*const main.StateMachineBuilder(tests.State,tests.Input,&.{ .{ ... }, .{ ... } }[0..2],.Idle,(function 'dummyStartFn'),(function 'dummyEndFn'),(function 'dummyErrFn'))'
    try std.testing.expect(my_special_project.currentState() == State.Idle);
 ......
[redacted][~//Coding/zig/my_special_project][main ?!] → 

Can someone explain why this behavior might be occurring? Is this more likely a bug in Ghostty or a misconfiguration on my system?

[mitchellh]

We use xdg-open, so its up to that.

[0x4a61636f62]

@mitchellh This seems to be related to #3476

When my prompt "gets clear" as it says in that issue, the behavior described in this issue occurs. I believe this is a bug.