nohup on Mac: Unlike GNU, It Never Redirects stdin

I started nohup cat > out.txt & in a terminal on my Mac mini and the shell answered suspended (tty input). The job had stopped before it read a byte. When I closed the terminal it was gone, nohup and all. The same line with GNU's nohup from Homebrew printed ignoring input, and cat exited at once instead of hanging. The difference sits in Apple's source: macOS nohup never touches standard input.

That's one of several ways "nohup mac" behaves differently from the Linux answers most people find. Below: what Apple's nohup actually does, line by line from its source, which background jobs survived a closed terminal in my tests on macOS 26.4.1, the exit codes, where nohup.out ends up, the old can't detach from console error, and a count of 983 Stack Exchange questions about nohup.

The short answer

# the form that behaves the same on macOS and Linux
nohup ./long-job.sh < /dev/null > job.log 2>&1 &
echo $! > job.pid          # keep the PID, you'll want it to stop the job

# zsh: background and disown in one step
./long-job.sh < /dev/null > job.log 2>&1 &!

# stop it later
kill "$(cat job.pid)"

The < /dev/null is the part Mac users miss. GNU nohup adds it for you when standard input is a terminal. Apple's doesn't, so anything that reads input stops in the background and dies when the terminal goes away.

What Apple's nohup actually does

The macOS command comes from Apple's shell_cmds nohup.c, a FreeBSD descendant of 149 lines. In order, it does four things and then runs your command:

Step	Apple /usr/bin/nohup	GNU nohup (coreutils 9.12)
stdin is a terminal	left alone	replaced with an unreadable descriptor, prints "ignoring input"
stdout is a terminal	appended to ./nohup.out, else $HOME/nohup.out, mode 0600	same files
stderr is a terminal	pointed at wherever stdout now goes	same
SIGHUP	set to ignored	set to ignored
Apple only	_vprocmgr_detach_from_console(), fails with "can't detach from console"	none
nohup's own failure	exit 127	exit 125

Both are legal. The POSIX nohup spec says nohup "may" redirect standard input, so leaving it alone is allowed, and it assigns 127 to both "nohup failed" and "command not found". GNU's manual documents its 125 as a deliberate extension. One 2023 answer on Stack Overflow's "can't detach from console" thread says nohup "redirects stdin from /dev/null if it was previously pointing to a terminal". That's the GNU behavior, and it's wrong for the binary a Mac ships with.

Which jobs survived a closed terminal

I ran each case in a zsh pane inside a separate tmux server, then killed the server, which hangs up the terminal the same way closing a Terminal window or dropping an SSH session does. Two seconds later I checked which processes were still alive:

Two of those results are traps.

A stopped nohup job dies anyway. Ignoring SIGHUP only helps a process that's running. Both of my nohup cat jobs were sitting in TN state waiting for terminal input, and neither was alive after the hangup. This is where the missing stdin redirect matters: any script that prompts, any read, any tool that checks for a key press will stop the same way.

& disown can disown the wrong job. With no argument, disown acts on the shell's current job, and zsh and bash both make a stopped job current ahead of a newer running one. With a suspended cat in the same shell, sleep 321 & disown printed disown: warning: job is suspended, disowned the cat, and left sleep 321 attached. It died with the terminal. In zsh, &! has no such ambiguity, and in either shell disown %3 names the job explicitly.

On the other side, nohup's protection is narrow. A child that resets the signal undoes it: a Python process started under nohup that set SIGHUP back to the default died on kill -HUP. nohup also does nothing about SIGTERM or SIGKILL, which is what process managers and agent harnesses send.

Exit codes: 127 means two things

Without a terminal, which is how launchd jobs, cron and CI run, I got these:

$ nohup nonexistcmd_zz; echo $?
nohup: nonexistcmd_zz: No such file or directory
127
$ nohup /etc/hosts; echo $?
nohup: /etc/hosts: Permission denied
126
$ nohup; echo $?
usage: nohup [--] utility [arguments]
127
$ nohup sh -c 'exit 127'; echo $?
127
$ nohup cd /; echo $?
0

A script can't tell "nohup failed", "the command wasn't found" and "the command itself exited 127" apart, because all three return 127. GNU's nohup returns 125 when it fails, and that's the one code it adds.

The last line is my favorite. Shell builtins can't run under nohup, because nohup needs an executable file. A shell function fails with No such file or directory and exits 127. But of the 20 builtin names I checked, 15 also exist in /usr/bin as the same three-line script: cd, alias, bg, fg, jobs, wait, read, umask, command, type, ulimit, getopts, hash, fc and unalias. Each one runs the builtin inside a throwaway sh. So nohup cd / changes the directory of a child shell that exits right away, and returns 0.

Where nohup.out goes, and what hides in it

In a terminal, nohup prints appending output to nohup.out and creates the file in the current directory with mode -rw-------. Later runs append to it. When the current directory isn't writable (I tried from /), it falls back to $HOME/nohup.out and says so. With neither writable it prints nohup: can't open a nohup.out file and exits 127.

The file is created before nohup looks for your command. So nohup typo-command in a terminal shows only appending output to nohup.out and returns 127. The actual error, No such file or directory, is written into nohup.out, because stderr was already pointed there.

The other common "nohup isn't working" report is an empty nohup.out from a Python script. Python buffers stdout when it isn't a terminal. In my test, a script that printed one line and slept for six seconds left a 0-byte file at 2.5 seconds and 5 bytes when it exited. With python3 -u the 5 bytes were there at 2.5 seconds. Nothing was lost. It just hadn't been written yet.

"nohup: can't detach from console"

The _vprocmgr_detach_from_console call is the one step only Apple's nohup has, and it produced the Mac-specific errors in this list: can't detach from console: Inappropriate ioctl for device (Stack Overflow, 2014 and 2016), No such file or directory (Yosemite, 2015) and Undefined error: 0 (over SSH, 2017). tmux issue #443 from June 2016 reproduced it inside tmux on Yosemite and El Capitan. The tmux maintainer called it "a bug either in OS X or in OS X nohup", and the working fix in that thread was starting the shell through reattach-to-user-namespace. For SSH, a 2017 answer on the Yosemite thread fixed it with UsePAM yes in sshd's config.

I couldn't reproduce it. nohup ran without the error in tmux 3.7c and from a launchd agent with no terminal. This Mac's /etc/ssh/sshd_config.d/100-macos.conf already sets UsePAM yes. I didn't test nohup over an SSH login. If you see the error today, the old workaround still applies: drop nohup and redirect all three streams yourself, then disown.

What 983 questions ask about

I pulled every question with "nohup" in the title from four Stack Exchange sites through the API on October 13, 2026: 983 questions, 9,100,660 views, asked between December 2008 and December 2025. I sorted them by title keyword. A title that matched more than one group went to the first group it matched, in the order of this table:

Title is about	Questions	Views	Share of views
Stopping it, finding its PID	112	1,613,556	17.7%
stdin, "ignoring input"	35	636,036	7.0%
nohup.out, output, logs	176	2,172,693	23.9%
Surviving logout, SSH, terminal close	146	410,294	4.5%
vs disown, screen, &	127	1,756,802	19.3%
Other	387	2,511,279	27.6%

Stack Overflow had 708 of them, Unix & Linux 220, Super User 52 and Ask Different 3. Only 23 mention macOS in the title or tags, with 75,421 views between them, and 3 of those 23 are the detach error. The single most-viewed question, at 738,237 views, is how to get the PID to kill a nohup process. That's why the short answer above saves $! to a file. In the stdin group, 6 titles that quote GNU's ignoring input message hold 510,602 of its 636,036 views. A Mac never prints that message, which is the clearest sign that most nohup answers describe the GNU tool.

nohup in headless and agent runs

I run this business from launchd jobs that start Claude Code in print mode, so I don't have a terminal to lose. There, nohup's file and SIGHUP handling mostly don't apply. What matters is whether a job outlives the session that started it. On September 15, an evening run started a model download with nohup from a Bash call. At 18:48 its handoff note said the download was 56% done. The next run found it finished at 19:20, with checksums matching the published ones. The harness's own background-task feature is a different story, which claude -p background tasks covers. If you then wait for a nohup job, wait on its PID. pgrep not working shows how pattern-based wait loops end up matching each other.

For anything that has to run for days, nohup is the wrong tool on a Mac. A LaunchAgent or LaunchDaemon restarts the job, logs it and survives a reboot. For an interactive session you want to come back to, use tmux. Claude Code in tmux lists the settings that matter there. And if a long job in your terminal dies with just zsh: killed, that's SIGKILL, which nohup was never going to stop. zsh killed on Mac goes through the usual causes.

FAQ

Does nohup work on Mac?

Yes. macOS ships /usr/bin/nohup, so there's nothing to install. It ignores SIGHUP and sends terminal output to nohup.out like the Linux version, but unlike GNU nohup it doesn't detach standard input from the terminal. Run nohup command < /dev/null > job.log 2>&1 & so a job that reads input doesn't stop in the background and die when the terminal closes.

Why did my nohup process stop when I closed Terminal on macOS?

Usually because it was stopped, not running. macOS nohup leaves standard input on the terminal, so a background job that tries to read input is suspended with "tty input", and a stopped job dies when the terminal hangs up even though SIGHUP is ignored. Redirect input from /dev/null. Also check disown: with no argument it can pick a different, stopped job.

How do I use nohup without creating nohup.out on Mac?

Redirect standard output yourself, for example nohup command > job.log 2>&1 & or nohup command > /dev/null 2>&1 &. nohup only creates nohup.out when standard output is a terminal, so once stdout points at a file it writes nothing of its own and prints no message.

How this was tested: Mac mini (Mac16,10), macOS 26.4.1 (25E253), /usr/bin/nohup dated April 6, 2026, zsh 5.9, tmux 3.7c, Homebrew coreutils 9.12 for GNU nohup, and the system Python 3.9.6, on October 13, 2026. The no-terminal runs came from a launchd agent. The terminal runs used a separate tmux server with a clean zsh -f and HOME pointed at a scratch folder, and "closing the terminal" means killing that tmux server. Every test process was stopped and the scratch folder deleted afterwards. The step table is read from Apple's published nohup.c, not from disassembling the installed binary. The detach error was not tested over SSH. The September 15 download is from my own run logs. The question counts come from the Stack Exchange API's title search on Stack Overflow, Unix & Linux, Super User and Ask Different, sorted by title keywords only, so a question titled "nohup not working" lands in "Other" whatever its body says, and "How to get the proper exit code from nohup" lands under surviving logout because its title contains "exit".