When a FUSE mount is not responding, Ghostty becomes unusable (Linux)

Open

jcollieopened 5d ago

Discussed in https://github.com/ghostty-org/ghostty/discussions/14836

^{Originally posted by marcelohdez October 24, 2026}

Issue Description

I use sshfs to connect to my university's Linux boxes and use Neovim on them locally. However I noticed that after my computer sleeps (and therefore the connection is interrupted,) all Ghostty windows are no longer usable until I kill sshfs or unmount the FUSE mount (through another terminal.)

Expected Behavior

For Ghostty to be able to handle input on other tabs/windows even if one is frozen.

Actual Behavior

All Ghostty windows and tabs are frozen.

Reproduction Steps

sshfs into a local device

mkdir user-dir
sshfs user@1.2.3.4: user-dir

Disable your internet (I used the GNOME quick settings toggle on Fedora)
Try to cd into a directory then tab into another from the FUSE mount.
You'll notice that the shell freezes.
Try to open any new Ghostty windows (frozen as well), or tabs, and try to close them (you can't.)

Video:

https://github.com/user-attachments/assets/1ff461cc-65b9-4144-bf36-dfd355e13a93

Ghostty Logs

No response

Ghostty Version

Ghostty 1.3.1-1.fc45

Version
  - version: 1.3.1-1.fc45
  - channel: tip
Build Config
  - Zig version   : 0.15.2
  - build mode    : .ReleaseFast
  - app runtime   : .gtk
  - font engine   : .fontconfig_freetype
  - renderer      : renderer.generic.Renderer(renderer.OpenGL)
  - libxev        : io_uring
  - kernel version: 7.2.9-301.fc45.x86_64
  - desktop env   : gnome
  - GTK version   :
    build         : 4.23.0
    runtime       : 4.24.1
  - libadwaita    : enabled
    build         : 1.9.0
    runtime       : 1.10.0
  - libX11        : enabled
  - libwayland    : enabled

OS Version Information

Fedora 45

(Linux only) Display Server

Wayland

(Linux only) Desktop Environment/Window Manager

GNOME 51.0

Minimal Ghostty Configuration

N/A

Additional Relevant Configuration

No response

I acknowledge that:

I have reviewed the FAQ and confirm that my issue is NOT among them.
I have searched the Ghostty documentation and confirm there doesn't exist a configuration option that solves my issue.
I have searched the Ghostty repository (both open and closed Discussions and Issues) and confirm this is not a duplicate of an existing issue or discussion.
I have checked the "Preview" tab on all text fields to ensure that everything looks right, and have wrapped all configuration and code in code blocks with a group of three backticks (```) on separate lines.

Activity

jcollie5d ago

Closing a surface: Surface.deinit joins the IO thread on the GTK main thread (src/Surface.zig:844).
The IO thread's exit runs subprocess.stop() → killCommand → killPid (src/termio/Exec.zig:1176).
killPid loops forever: send SIGHUP to the process group, check with a non-blocking waitpid, sleep 10 ms, repeat until the child is reaped. It never moves on to SIGKILL. The comment on stop() says it "will not block", but it does.
During tab completion, the shell itself is the process making the FUSE request (readdir/stat), and interactive shells catch SIGHUP. The kernel only cuts a FUSE request short for a signal that would kill the process, so a caught SIGHUP leaves the shell blocked for good. The loop never ends, the join never returns, and the GTK main loop is stuck.