macOS 27: Cannot access LAN due to App Sandboxing

[hschneider]

Issue Description

Trying to use SSH to connect to another machine in my LAN, fails:

$ ssh imac2.local
ssh: connect to host imac2.local port 22: Undefined error: 0

Expected Behavior

The SSH connection should be established.
The app should be available under System Settings / Privacy / Network Access, so it can be enabled to access networking outside its sandbox.

Actual Behavior

Routing is blocked by macOS Sandbox.
Ghostty is not available under System Settings / Privacy / Network Access, so it cannot be enabled to access the network.

When I start Ghostty from the builtin macOS terminal like this:

/Applications/Ghostty.app/Contents/MacOS/ghostty &

Then SSH works as expected inside Ghostty.

Reproduction Steps

1. Open Ghostty from dock
2. Type ssh SOME_HOSTNAME OR IP

Ghostty Logs

No response

Ghostty Version

Ghostty 1.3.1

Version
  - version: 1.3.1
  - channel: stable
Build Config
  - Zig version   : 0.15.2
  - build mode    : .ReleaseFast
  - app runtime   : .none
  - font engine   : .coretext
  - renderer      : renderer.generic.Renderer(renderer.Metal)
  - libxev        : kqueue

OS Version Information

macOS 27.0

(Linux only) Display Server

None

(Linux only) Desktop Environment/Window Manager

No response

Minimal Ghostty Configuration

background-opacity = 0.95
window-padding-x = 15
font-size = 13

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 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.

[bo2themax]

Normally all app should have network access on Mac, you should enable Ghostty in Local Network in privacy settings tho. I think you denied that before

[hschneider]

No, the app does not show up in the privacy settings.
Even moving it out and back into the programs folder does not trigger it to show up.

[bo2themax]

Well, I can connect with no problem, it could your firewall setting issues. And yes you're right, there's no popup (I did tccutil reset All), but it doesn't affect anything for me

[hschneider]

Firewall is OK. It all works fine, if I start Ghostty from the macOS terminal.
I see you have 1.3.2, mine is 1.3.1.
Where can I download 1.3.2 ?

[bo2themax]

You can add auto-update-channel = tip to you config file, reload the config and check updates. But i don't think it's related.

It all works fine, if I start Ghostty from the macOS terminal.

Can you expand on this? Did you mean launching Ghostty in Terminal by /Applications/Ghostty.app/Contents/MacOS/ghostty? It works fine in this case?

[hschneider]

Thanks, I will try 1.3.2.

I open the macOS builtin Terminal App and start Ghostty with this command:

/Applications/Ghostty.app/Contents/MacOS/ghostty

Then SSH works inside Ghostty.

[hschneider]

Same behavior with

Ghostty 1.3.2-main-+e6e26e165

Version
  - version: 1.3.2-main-+e6e26e165
  - channel: tip
Build Config
  - Zig version   : 0.16.0
  - build mode    : .ReleaseFast
  - app runtime   : .none
  - font engine   : .coretext
  - renderer      : renderer.generic.Renderer(renderer.Metal)
  - libxev        : kqueue

[bo2themax]

Can you stream logs in Console.app by filtering any:<IPv4-redacted>:22, reproduce in Ghostty, locate the error entry and clear filters. See if you can find any strange errors. BTW, we didn't enable sandbox on macOS.

[hschneider]

Looks like this is not an Ghostty issue, because doing

sudo ssh SOME_HOST

works!

Maybe some macOS 27 beta-quirk ...

[bo2themax]

This sounds more like a shell integration/terminfo related issue.🫪

[hschneider]

There are still 2 strange things:

1. Starting Ghostty from the macOS Terminal App works.
2. sudo inside Ghostty works.

What happens is
Case 1:
The Ghostty subprocess inherits the networking entitlements from Terminal.
Case 2:
sudo bypasses the Sandboxing restrictions.

Maybe a macOS 27 Sandboxing issue?
Or missing entitlements of Ghostty?

[hschneider]

Maybe these entitlements need to be added:

Entitlement Key	Description
com.apple.security.network.client	Allows outgoing network socket connections.
com.apple.security.network.server	Allows listening for incoming network sockets.
com.apple.developer.networking.multicast	Allows sending/receiving local network multicast packets (MDNS, local discovery).

[D0ntPanic]

I have this issue as well, and for me it seemed to show up after installing beta 4. I got a bunch of new permission prompts once it installed, but Ghostty never asked for local networking permission even when I tried to ssh into a local machine.

I had a completely unconfirmed theory: what if child processes aren't triggering local network allow prompts anymore? I tested this theory by letting Claude add a menu option to access the local network from the Ghostty process itself instead of a command run from inside a shell. After selecting this menu option, the local network allow prompt appears, and once it does, local network commands from the terminal also work. Surprisingly, the official build allows local networking once I did this test.

I have no confirmation that this is required to actually fix the issue, or that it is in any way a reasonable fix, but it does seem that macOS 27 beta 4 has changed something about how the local networking allow requests work.

[maddler]

using sudo by default is a bit too extreme. As ugly as it is, for now, I'm just launching the initial session via Terminal. That's OKish for the time being.

[maddler]

Ok, this is a bit weird. I've found that SSG works for one and only one host on my network. But behavior is consistent across Ghostty, iTerm and Warp.

[saagarjha]

I have SIP off, so take this with a grain of salt, but I ran into this too and things are working now after turning on local network access for iTerm. I think literally running python -m http.server makes it show up

[maddler]

I confirmed the issue with iTerm, Warp and Ghostty.

The pyton command will indeed raise a request to Local Network, but that will only be effective for python. Both iTerm and Ghostty are still unable to access. I tried with (brew) ssh and nc, and they will both fail.

[hschneider]

Confirmed:

$ python -m http.server
Serving HTTP on :: port 8000 (http://[::]:8000/) ...

# This shows up SIP and the HTTP Server can be reached from outside.
# But this error remains:

hschneider@MBP16 ~
$ ssh -l hschneider imac2.local
ssh: connect to host imac2.local port 22: Undefined error: 0

The SIP dialog adds Python, not Ghostty to the privacy settings.

[hschneider]

Good news :-)
This has been solved with the latest version:

Version
  - version: 1.3.2-main-+2dd79f3bc
  - channel: tip
Build Config
  - Zig version   : 0.16.0
  - build mode    : .ReleaseFast
  - app runtime   : .none
  - font engine   : .coretext
  - renderer      : renderer.generic.Renderer(renderer.Metal)
  - libxev        : kqueue

To get this release, add

auto-update-channel = tip

to your settings.

Thanks for the quick solution!

[hschneider]

Ouch ... this is crazy.
It worked 2 times and then stopped working .. :-/

I was able to use sshand ping successfully.
When trying ssh to the same host again, it fails with the old behavior.
Ghostty was left open, no restart.

The 2 times it worked, the Terminal window showed a shield-icon, then never again.

Maybe Gatekeeper does something strange in the background after updating the app ...

[bo2themax]

I don't think tip has new commits regarding this. But I do encounter network issues myself on macOS 27 beta, that's related to the Virtualization framework, not Ghostty itself.

Each time I open UTM some of the remote hosts will be unreachable, then I'll need to restart my laptop.

[maddler]

On latest tip, and there's 100% no difference compared to before. What I've noticed is some hosts on the same local subnet seem to be working. Definitely a beta/OS issue rather than anything with Ghostty and other terminal apps.

[sviperz]

Opened a bug via Apple's Feedback Assistant - FB24035385.

[pratikngupta]

I experienced the same issue across multiple applications (Warp, iTerm2, VS Code, and Ghostty) running macOS 27 Developer Beta.

Deleting the network configuration PLIST files and re-approving permissions fixed the issue. Because these files are protected by System Integrity Protection (SIP) on modern macOS versions, you need to temporarily disable SIP to remove them.

Instructions

1. Boot into Recovery Mode

   • Restart your Mac mini and press and hold the Power button until the startup options screen appears.
   • Select Options to enter macOS Recovery.

2. Disable SIP Temporarily

   • From the top menu bar, open Utilities > Terminal.
   • Run the following command and then restart the mac normally

csrutil disable

3. Delete Network Cache Files
   • Open your standard terminal application and execute the following commands to clear the corrupt network permission caches:

sudo rm /Library/Preferences/com.apple.networkextension.plist
sudo rm /Library/Preferences/com.apple.networkextension.uuidcache.plist

4. Re-enable System Integrity Protection
   • Reboot back into Recovery Mode.
   • Open Utilities > Terminal and re-enable SIP > then restart the mac normally

csrutil enable

---

I have tried the above steps on following MacBook and all the apps where working again after resetting the network configuration PLIST.

1. Macbook Air M1
2. Macbook Pro M5 pro

I hope this is temporary solution, and apple fix the underlying issue that is causing the plist file to corrupt.

[hschneider]

I also filed a Feedback (FB24085834) linked to your findings and workaround.

[Jerdle]

Confirming this approach worked for me, but I had to take a slightly different route. In Recovery terminal, I mounted the Data volume and rather than deleting the plists, I moved them to .bak versions and rebooted normally. Ghostty and all my other Local Network apps are working as expected now.

[maddler]

Did anybody verify this with today's Developers Beta 5? Changelog doesn't seem to be mentioning anything related to this.

https://developer.apple.com/documentation/macos-release-notes/macos-27-release-notes#Resolved-Issues

[hschneider]

On my machine the issue seems to be solved with Beta5 !

[maddler]

Ah, nice! I'll let it sink for a couple days and might give it a go then!

[D0ntPanic]

Fixed for me on beta 5 as well

[maddler]

Can confirm everything now works both on DP 5 and Open Beta 3.

[oschrenk]

Still happens to me :(

Tmux via Ghostty

❯ ssh pi-1.local
ssh: connect to host pi-1.local port 22: Undefined error: 0

❯ sw_vers
ProductName:		macOS
ProductVersion:		27.0
BuildVersion:		26A5406e

via Terminal it works fine

[maddler]

I got the Local Network access request 1st time I tried and been working fine since. Same behaviour with Warp.

❯ sw_vers
ProductName:            macOS
ProductVersion:         27.0
BuildVersion:           26A5406e
❯ nc -vz -w 5 192.168.50.150 22
piattola.eth0.lan [192.168.50.150] 22 (ssh) open

[oschrenk]

It has to do with tmux.

Hoe to reproduce

1. Open Ghostty. Open tmux session. ssh pi-1.local works
2. Close Ghosty.
3. Open Ghostty. Resume tmux session. ``ssh pi-1.local` doesn' work.

I assume first tmux, inherits network permission from first ghostty instance. After that process is closed, its no longer valid and can't gain network access.....

Defeating the whole purpose of tmux (for me).

Edit:
Submitted Apple Feedback FB24336317. It kind of kills tmux

[maddler]

ah, gotcha now! Yes, failing for me too.
Screen doesn't look to be affected.

They're definitely changing something around the Local Network permissions.

[Write]

Same issue with herdr here :(