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.

[mybigman]

This was it. I dont even recall seeing a popup and I only recently switched to ghostty from iterm2.

It is resolved for me now. thanks.

[fooness]

That’s not the issue for me (and some other commenters here, according to their comments/reports); the permissions are correct, the networking works inside Ghostty without a terminal multiplexer like tmux, but not within tmux after an update.

[edrozenberg]

...but not within tmux after an update.

Are you using ssh agent forwarding by any chance?

Found several older references to tmux issues related to SSH_AUTH_SOCK. But not sure it's even relevant any more with recent tmux versions.

Tmux and SSH agent forwarding
without-brains.net/2020/08/05/tmux-and-ssh-agent-forwarding/

tmux: Cannot SSH from inside tmux, even though I have agent-forwarding (ssh -A) on [duplicate]
superuser.com/questions/334975/tmux-cannot-ssh-from-inside-tmux-even-though-i-have-agent-forwarding-ssh-a

tmux cannot work with ssh-agent
stackoverflow.com/questions/49382507/tmux-cannot-work-with-ssh-agent

[fooness]

Are you using ssh agent forwarding by any chance?

No.