Telnet on Mac: brew telnet Exits 1 Even When It Connects

I installed telnet on my Mac mini with Homebrew and pointed it at a local web server that was definitely up. It printed Connected to localhost. and then exited with status 1. It also exited 1 against a closed port, a port that drops packets, and a host name that doesn't exist. If you were planning to use telnet in a script to check whether a port is open, its exit code tells you nothing.

macOS hasn't shipped telnet since High Sierra (10.13). The first public report I found is a June 2017 Apple Developer Forums thread from the 10.13 beta, and Apple never posted a reason in it. So the real question behind "telnet mac" is what to use instead. I ran the Homebrew telnet and eight commands that already work on a stock Mac against seven targets and recorded the exit code, the time and the message for each. That's 63 runs. Two of the replacements have traps of their own, and one result only shows up when telnet runs from something other than Terminal.

The short answer

# is the port open? exit 0 = yes, 1 = no; -G caps the connect wait (Apple nc only)
nc -vz -G 3 host 443

# talk to it: send a request and read the reply (curl waits for the server)
printf 'HEAD / HTTP/1.0\r\nHost: example.com\r\n\r\n' | curl -s telnet://example.com:80

# the real telnet client, if you need it (Apple's own source, version 308)
brew install telnet

If you only type telnet host port to see whether something answers, nc -vz is the replacement, and it's in /usr/bin already. Add -G. Without it, a firewalled port holds the command for 75 seconds.

What each tool returned

Targets were a local Python web server on 127.0.0.1 (open), the next port up (closed), 192.0.2.1:80 (a documentation address nothing answers, so the connection just hangs), example.com:80, Gmail's mail server on port 25, my router, and nosuchhost.invalid. Each run was wrapped in a 100-second cap.

Command	Open port	Closed port	No answer	Bad host
nc -vz	0, 0.04 s	1, 0.04 s	1, 75.18 s	1
nc -vz -G 3	0	1	1, 3.06 s	1
nc -vz -w 3	0	1	1, 75.06 s	1
curl telnet:// (--connect-timeout 3 --max-time 5; the run without --connect-timeout matched it)	28, 5.14 s	7	28, 3.17 s	6
bash /dev/tcp	0	1	1, 75.07 s	1
zsh ztcp	0	1	1, 75.07 s	1
Python socket, timeout 3	0	1	1, 3.09 s	1
Homebrew telnet	1	1	1, 75.08 s	1

Three things in that table are worth knowing before you write a script.

telnet's exit code is always 1 here. The runs fed it an empty stdin, which is what a script or a pipe does. telnet connects, sees end of input, closes, prints Connection closed by foreign host. and exits 1. The same 1 comes back for a refused connection and for a timeout. The only way to tell them apart is to read the text.

nc -w is not a connect timeout on a Mac. On Linux, nc -w 3 is the usual answer for "don't hang". Apple's nc took 75.06 seconds with it, the same as with no flag. Apple's build has its own option for that, -G conntimo, listed in nc -h as "Connection timeout in seconds". With -G 3 the same probe ended in 3.06 seconds. 75 seconds is the macOS default, and bash, zsh and telnet all waited exactly that long.

curl returns 28 for an open port. curl telnet:// connects and then keeps the session open until --max-time runs out, so a working port ends with exit 28, "Operation timed out". A firewalled port ends with 28 too. Only a refused port gives a distinct code (7). curl is good for sending something and reading the answer, and it's the wrong tool for "is it open".

Piping a request in: nc returns nothing, telnet adds NUL bytes

The other thing people use telnet for is typing a raw request: an HTTP HEAD, an SMTP EHLO. In a script that becomes a pipe, and the pipe behaves differently per tool.

printf 'HEAD / HTTP/1.0\r\nHost: example.com\r\n\r\n' | nc example.com 80
# exit 0, 0.30 s, no output at all

(printf 'HEAD / HTTP/1.0\r\nHost: example.com\r\n\r\n'; sleep 3) | nc example.com 80
# HTTP/1.1 200 OK ...

printf 'HEAD / HTTP/1.0\r\nHost: example.com\r\n\r\n' | curl -s telnet://example.com:80
# HTTP/1.1 200 OK ... exit 0, 0.53 s

Apple's nc closed the connection as soon as its input ran out, before the server replied, and still exited 0. -w 5 didn't change that. Keeping stdin open with a sleep works, but you have to guess the delay. curl waited for the server to close and printed the full response in half a second. bash's exec 3<>/dev/tcp/example.com/80 followed by a write and a read also worked.

telnet with a pipe printed nothing either (exit 1, 0.15 s). With a sleep added it did get a reply: HTTP/1.1 400 Bad Request from Cloudflare. I pointed telnet at a small Python listener to see what it sent. My \r\n arrived as \r\x00\r\n. telnet follows the telnet protocol, and RFC 854 says a carriage return not followed by a line feed must be sent as CR NUL. Feed telnet plain \n line endings and it sends a clean \r\n. telnet is a protocol client, not a raw TCP pipe. nc and curl's telnet:// pass bytes through untouched.

Homebrew telnet couldn't reach my LAN at all

This one I did not expect. Against my router, every Apple tool waited 75 seconds and timed out (nothing answers on those ports, so the connection just hangs). Homebrew telnet failed in 0.04 seconds with No route to host. I checked a second machine on the network: nc -z connected to 192.168.20.10 on ports 80, 443 and 22, and telnet got No route to host on all three. Homebrew's wget got the same error. Connections to example.com and to my own LAN address worked fine for all of them.

The cause is macOS local network privacy, added in macOS 15. Apple's TN3179 lists what is allowed automatically: daemons started by launchd, anything running as root, and "command-line tools run from Terminal or over SSH, including any child processes they spawn". It adds that the launchd daemon exception "doesn't apply to launchd agents". My shell doesn't run from Terminal. It runs under a launchd agent that starts Claude Code, and at the moment of the test the system log has nehelper looking up com.anthropic.claude-code, the app it holds responsible. That app has no Local Network permission, so the ad-hoc-signed Homebrew binaries were refused. Apple's own /usr/bin/nc, bash, zsh and the Command Line Tools Python were not.

If you type telnet in Terminal, you won't see this. If you call telnet from an IDE terminal, a launch agent, an automation app or an AI agent and get No route to host for a machine that's plainly up, check System Settings > Privacy & Security > Local Network for the parent app. The same symptom shows up in my notes on the route command, where an Ask Different question has telnet to a LAN host failing on Sequoia until it runs with sudo. Root is on the exempt list.

Getting the real telnet back

brew install telnet took a few seconds and installed a 210.5 KB bottle. The formula builds Apple's own remote_cmds-308 source, so it's the same client older macOS had. Homebrew counted 124,557 installs of it in the last 365 days, so plenty of people still want it. brew install inetutils gives you GNU's version instead; the two conflict, so pick one.

The formula only has prebuilt bottles for Apple silicon on Sonoma, Sequoia and Tahoe (plus one pre-release macOS) and for Intel on Sonoma. Anything else builds from source, and the formula declares depends_on xcode: :build, which means full Xcode, not just the Command Line Tools. That probably explains part of the old "can't install telnet with Homebrew" questions. One more fallback you'll see suggested is python3 -m telnetlib. It still works with the macOS system Python (3.9.6), but PEP 594 removed telnetlib in Python 3.13, so a newer Python won't have it.

What people actually ask

I pulled all 19 Ask Different questions with "telnet" in the title through the Stack Exchange API. Together they have 441,327 views. Six are about getting telnet back after 10.13; those six account for 155,337 views, and the top one, from September 2017, is the "How to get BSD FTP and Telnet back in 10.13" thread whose answer is the Homebrew formula above. Seven are connection troubleshooting, four are about scripting or sending text, and two ask how to run a telnet server. For the connection questions, nc with -G gives a clean yes or no. For checking which process holds a port on your own Mac, use lsof as in killing a process on a port instead, and if the problem is one layer down, ping on a Mac has its own surprises.

FAQ

Does telnet work on Mac?

Not out of the box. Apple removed the telnet client from macOS in High Sierra (10.13), and it is still missing on macOS 26. You can install Apple's own telnet source with brew install telnet, or use the built-in nc to test ports: nc -vz -G 3 host port exits 0 if the port is open and 1 if not.

How do I install telnet on Mac?

Install Homebrew, then run brew install telnet. It installs a prebuilt binary on Apple silicon Macs running Sonoma, Sequoia or Tahoe and on Intel Macs running Sonoma; other systems build it from source and need full Xcode. brew install inetutils installs the GNU version instead. The two packages conflict, so install only one.

What can I use instead of telnet on Mac to test a port?

Use nc, which ships with macOS: nc -vz -G 3 host port. Add -G because Apple's nc ignores -w for the connection itself, and without a timeout a firewalled port makes it wait 75 seconds. To send a request and read the reply, pipe it into curl telnet://host:port, which waits for the server's answer; plain nc closes as soon as its input ends.

How this was tested: Mac mini (Mac16,10), macOS 26.4.1 (25E253), Apple nc from /usr/bin, curl 8.7.1, bash 3.2.57, zsh's zsh/net/tcp module, Command Line Tools Python 3.9.6, and Homebrew telnet 308 (installed for the test and removed afterwards), run as a normal user from a launchd agent rather than Terminal. Nine commands (two of them curl variants) ran against seven targets, each capped at 100 seconds, on Wi-Fi; the open-LAN-host check and the byte capture through a Python listener were run separately. The Ask Different count covers every question with telnet in the title returned by the Stack Exchange API on October 13, 2026. Install counts are from Homebrew's analytics for the telnet formula on the same day. For the curl side of this, see which curl a Mac ships.