Network connections like ssh within tmux are broken after updating Ghostty

[fooness]

This is a weird one, and I’m not sure I can describe it rather good, but I can reproduce the problem.

1. Start Ghostty
2. Run tmux to start new session
3. Run e.g. ssh <remote> -> connection established
4. Check for Ghostty update
5. Update/Restart Ghostty
6. Run tmux attach
7. SSH connection was closed
8. Run e.g. ssh <remote> -> "No route to host"
9. Run ping <remote> -> this does work, though
10. Quit tmux session
11. Run tmux to start new session
12. Run e.g. ssh <remote> -> connection established

I am on macOS Sequoia, my macOS Firewall is enabled, and I run Little Snitch; but neither the enabled macOS Firewall nor running Little Snitch should matter here, as everything works as expected until updating Ghostty, and work again after quitting and starting tmux again.

[mitchellh]

This is weird enough that I'm going to make it a Q&A until we get some additional confirmation here. We have a LOT of tmux users and a lot of infrastructure folks in the beta so I would've expected to hear something like this before. So I want to just clear it up in discussions until we convert to an issue.

[fooness]

Update: For me, the issue still persists through v1.0.0 and v1.0.1 …

Unfortunately though, I myself am not really sure on how to inspect or debug this issue any further.

[hvdute]

I'm using ghostty version a2445359 on macos 15.2 and this problem still happens. It happens randomly since i started using ghostty. Mostly when connecting to services running on LAN. For example:

It works when detached from tmux session. After running tmux kill-server and start tmux over again, it works.

[kassadin]

PING 192.168.31.167 (192.168.31.167): 56 data bytes
ping: sendto: No route to host
ping: sendto: No route to host
Request timeout for icmp_seq 0
ping: sendto: No route to host
Request timeout for icmp_seq 1
ping: sendto: No route to host

I tested in Terminal, WezTerm, and iTerm2, and only Ghostty didn't work.
However, it can ping the gateway(192.168.31.1)

[mybigman]

This should be flagged as a bug not a discussion.

This is definitely an issue... I cant ping or ssh to anything on my local network using ghostty.

Everything works in terminal or iterm2.

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.none
  - font engine: font.main.Backend.coretext
  - renderer   : renderer.Metal
  - libxev     : main.Backend.kqueue

macOS Sequoia 15.2

> ssh [email protected]
ssh: connect to host 192.168.1.71 port 22: No route to host

> ping 192.168.1.71
PING 192.168.1.71 (192.168.1.71): 56 data bytes
ping: sendto: No route to host
ping: sendto: No route to host
Request timeout for icmp_seq 0

> nmap -sS -O -p22 192.168.1.71
Starting Nmap 7.95 ( https://nmap.org ) at 2025-01-30 19:22 AEDT
Nmap scan report for 192.168.1.71
Host is up (0.017s latency).

PORT   STATE SERVICE
22/tcp open  ssh

[rhodes-b]

This should be flagged as a bug not a discussion

this -> This is weird enough that I'm going to make it a Q&A until we get some additional confirmation here. We have a LOT of tmux users and a lot of infrastructure folks in the beta so I would've expected to hear something like this before. So I want to just clear it up in discussions until we convert to an issue.

Nobody said this isnt a bug. It seens only very small number of users having are having this issue. Things get converted into an issue (github issue) when its actionable (reproducible) until then it stays as a discussion to figure out what is going on

[fooness]

I just updated to version 1.1.0, re-attached my tmux session, and the problem still persists; I had to kill my tmux session and start all over, and then ssh, ping, etc. started working again.

[mybigman]

ive upgraded to 1.1.0 still same issue persists

[taylrfnt]

Been doing some digging on a similar issue report that came through the Discord... not sure if this is universal or limited to MacOS, but the majority of the reports below appear to be limited to MacOS, so sharing what appears to work for most cases. I have not been able to reproduce the issues within tmux, but anything outside a multiplexer should work with the fix below:

Apple has added some "enhanced security" features across various macOS versions that (sadly) most users tend to decline/dismiss, since it is not well-documented. In particular, on fresh installs, Ghostty (or any app that uses select network tools/features, for that matter) will request access to access devices on your local network. If you decline/dismiss, it kneecaps Ghostty's access to the network, including things like ping, telnet, etc.

You can use Apple's documentation to allow Ghostty permissions on your local network, fully quit (super+q) Ghostty, then relaunch and it should work. Apple unfortunately does not have a good document on the initial alert itself, and I can't reliably get it to appear, so I'll add a screenshot the next time I encounter it as a reply to this comment.

[fooness]

Are you using ssh agent forwarding by any chance?

No.

[mrbuk]

I had a similar issue but IMO this was related to tmux itself and how it behaves with the new Sequoia Local Network Privacy feature.

I typically observed the behaviour after

1. running tmux for some time including couple of laptop sleep states or
2. after the instance of Terminal / ghostty was terminated but the tmux server continued running.

So my assumption is that tmux somehow gets attached / associated to the Local Network Privacy of the process that is used to start the tmux server.

To address this I now start tmux using launchd. After doing this the first time I ran a ssh in a newly created tmux session and got the following pop-up asking for permissions.

So far I have not run into the issue again.

[fooness]

The issue might indeed be related to the Local Network Privacy feature, but it’s kinda weird that this problem happens in Ghostty, but not in e.g. iTerm2 or Terminal.app …

[jasondinh]

@fooness it happened with Terminal.app for me. I'm doing the launchd thing and tmux is now properly allowed to access local network, hopefully it won't break again. If it does I will come back and update this comment.

[jlehtimaki]

For me it got broken, again.

[afonsofrancof]

I just spent 30 minutes trying to understand why I couldn't ssh to my Raspberry Pi from my M3 MacBook Pro.
Pinging the host worked, and using netcat on port 22 worked, and I could see ssh traffic on Wireshark, but not when using the ssh command directly. I kept getting "no route to host".

Somehow my tmux instance got borked and now this error shows up regardless of which terminal emulator I use.
I don't know if ghostty broke my tmux session, but I am leaving this info here, hoping it can help.

[taylrfnt]

Did you try the solution recommended just a few posts above yours? If so, did it work?
#2998 (reply in thread)

[afonsofrancof]

I never got the prompt asking for permission to access my LAN.
I checked in the settings and tmux is not listed there so I can't toggle it on. There is also no way to add apps manually in the settings.
I will try to use launchd to launch it and see if it asks for permission.
Thanks!

[edrozenberg]

Something else to try is to navigate to where the binary is using Finder or other file mgr, then right click -> Open on the binary. This can help trigger whatever MacOS permissions are involved, for ex. it can help trigger the item to show up in System Settings -> Privacy & Security -> Allow to Open for the binary item.

[fooness]

Yes, but that’s unrelated to the problem description.