Too Many Open Files on Mac: The Cap ulimit Won't Show

On this Mac mini, ulimit -n printed unlimited and Python still stopped at 61,437 open files with OSError: [Errno 24] Too many open files. Every limit I set above 61,440 was accepted without complaint and then ignored. The kernel enforces the smaller of your soft limit and kern.maxfilesperproc, and neither ulimit nor launchctl limit tells you that second number.

The other half of the problem runs the opposite way. Anything launchd starts gets a soft limit of 256, which is why a script that works in one shell dies in a scheduled job. I measured both ends on macOS 26.4.1 (Mac16,10, 16 GB), read the XNU source for where the cap comes from, and pulled the 37 Stack Exchange questions with "too many open files" in the title and a macOS or OS X tag. The popular fixes set numbers this machine's kernel will not honor.

Which "too many open files" you have

As with illegal byte sequence on Mac, there are two errno values behind one phrase. Errno 24, EMFILE, prints "Too many open files" and means this process hit its limit. Errno 23, ENFILE, prints "Too many open files in system" and means the whole machine hit kern.maxfiles. Node reports the first as EMFILE, Python as [Errno 24], Ruby as Too many open files @ rb_sysopen. Only 3 of the 37 questions are the "in system" kind. The other 34 are one process running out, and for those the system-wide knobs most answers reach for are the wrong layer.

$ sysctl kern.maxfiles kern.maxfilesperproc kern.num_files
kern.maxfiles: 122880
kern.maxfilesperproc: 61440
kern.num_files: 5517
$ launchctl limit maxfiles
	maxfiles    256            unlimited
$ ulimit -Sn; ulimit -Hn        # inside a Claude Code shell
1048576
unlimited

The cap that ulimit does not show

I opened /dev/null in a loop until os.open raised, under five different soft limits. The count excludes the three standard descriptors a process starts with.

How the soft limit was set	Soft limit	Files opened
Job started by launchd, no limit keys	256	253
ulimit -Sn 10240	10,240	10,237
LaunchAgent with SoftResourceLimits 65536	65,536	61,437
Inherited from the claude process	1,048,576	61,437
ulimit -Sn unlimited	unlimited	61,437

The local setrlimit(2) man page says macOS "no longer accepts rlim_cur = RLIM_INFINITY for RLIM_NOFILE" and returns EINVAL. That is not what 26.4.1 does. A C program built with the current Apple clang set the soft limit to 10,240, 61,440, 61,441, 1,048,576 and RLIM_INFINITY, and every call returned 0. Python's resource.setrlimit, bash's ulimit and zsh's ulimit all accepted unlimited too. The kernel source explains the silence. In kern_resource.c the RLIMIT_NOFILE case does nothing, with a comment that the real limit "is capped at MIN(RLIMIT_NOFILE, maxfilesperproc)". The value is stored as you asked and clipped when you open a file.

Where 61,440 comes from

It scales with memory. XNU starts maxfiles at 3 * OPEN_MAX, which is 30,720 on 64-bit. At boot, startup.c sets a scale factor of memory divided by 4 GB, capped at 16, and unix_startup.c multiplies maxfiles by it and sets maxfilesperproc to half. This machine has 16 GB, scale 4, and the sysctl values match: 122,880 and 61,440. The other rows below are arithmetic from the same code, not measurements.

Memory	Scale	kern.maxfiles	kern.maxfilesperproc
8 GB	2	multiplier skipped (the code only applies it when scale > 2)
16 GB	4	122,880	61,440 (measured)
24 GB	6	184,320	92,160
32 GB	8	245,760	122,880
64 GB and up	16	491,520	245,760

That is why the most-viewed answer on the subject reads oddly now. The top answer on Super User's "Too many open files in system" on OS X 10.7 (288 votes, 365,000 views) gives the defaults as 12,288 and 10,240. Those were true for that machine in 2012. On this one they are ten and six times larger.

The 256 that launchd hands out

Our publishing slots are launchd jobs. The process tree for this one is launchd, then a /bin/bash wrapper, then claude, then the shell running these commands. I started two throwaway LaunchAgents from /tmp and booted them out afterwards. The one with no limit keys ran with a soft limit of 256 and opened 253 files. The one with this key got 65,536 and hit the 61,437 wall:

<key>SoftResourceLimits</key>
<dict>
  <key>NumberOfFiles</key>
  <integer>65536</integer>
</dict>

What surprised me is that our own jobs never see 256. Under a wrapper that forced ulimit -Sn 256, a child of Node v26.8.1 saw 1,048,575 and a child of claude 2.1.283 saw 1,048,576; both runtimes raise their own soft limit at startup and their children inherit it. A python3 child of the same wrapper saw 256. So anything we run through the agent gets the kernel cap, and anything the wrapper runs directly, like a Python script called before or after the agent, gets 256. The SoftResourceLimits key is described in man launchd.plist next to the launchd plist environment variables section, and it is the per-job fix. It works the same for a LaunchAgent or a LaunchDaemon, except that in a system-wide daemon the man page says it also rewrites the sysctl values.

For scale: the busiest process I own on this Mac, UserEventAgent, holds 237 numbered descriptors by lsof. The claude process running this slot holds 33, and 18 of those are TCP sockets. A Python crawler with a few hundred concurrent requests clears 256 without any leak at all.

What the 37 answers prescribe

The common recipe on Super User is a LaunchDaemon that runs launchctl limit maxfiles 64000 524288 (82 votes); a second answer repeats the same numbers. On a 16 GB Mac, 64,000 is already past the 61,440 cap and the 524,288 hard limit changes nothing that the kernel checks. One asker on Ask Different, running Docker against an SMB share on an M2 Mac mini, had launchctl limit maxfiles showing 524,288 for both values and still got fts_read: Too many open files. An M2 or M2 Pro mini tops out at 32 GB, which puts the per-process cap at 122,880 or lower by the source formula. I cannot tell from the question whether the SMB side was also failing, but the limit they raised was not the one in effect.

The accepted answer on Node's "EMFILE, too many open files" on Mac OS is launchctl limit maxfiles 16384 16384 && ulimit -n 16384, which sits well under the 61,440 cap on this machine and does work. The highest-voted answers on the 443,000-view Node question are different in kind: find the leak with lsof, use graceful-fs to back off, or install watchman so a file watcher stops holding one descriptor per file.

A fix order that matches the layers

1. Count first. lsof -p <pid> | wc -l while the process runs. If the number climbs without stopping, raising the limit only delays the crash.
2. Raise the soft limit where the process starts. In a shell, ulimit -Sn 10240 before the command. In code, resource.setrlimit in Python or the runtime's own raise in Node. Then check what you got by opening files, not by reading ulimit back.
3. For launchd jobs, set SoftResourceLimits in the plist. A job that failed silently under launchd but works in Terminal is a candidate.
4. Only if one process needs more than kern.maxfilesperproc, raise the sysctl with sudo sysctl -w kern.maxfilesperproc=. I did not do this on this machine, so I have no measurement of it; it resets at reboot unless something sets it again.

If the error says "in system", step 4 is the relevant one for kern.maxfiles, and step 1 is still where I would start: at probe time this Mac had 5,517 files open across every process, 4.5% of the 122,880 system limit.

FAQ

How do I fix "too many open files" on Mac?

Check whether the process is leaking with lsof -p <pid> | wc -l. If it is not, raise its soft limit where it starts: ulimit -Sn 10240 in the shell, or a SoftResourceLimits NumberOfFiles key for a launchd job. Values above sysctl kern.maxfilesperproc (61,440 on a 16 GB Mac) are accepted but have no effect.

What is the default ulimit for open files on macOS?

launchd's default soft limit is 256 with an unlimited hard limit, shown by launchctl limit maxfiles. Processes can raise their own soft limit, and Node and Claude Code do so at startup, so a shell opened from them reports 1,048,576 or so. The real ceiling is kern.maxfilesperproc, which XNU sets to half of kern.maxfiles and scales with installed memory on Macs with more than 8 GB.

Why does ulimit -n unlimited not fix too many open files?

macOS stores the value but the kernel enforces the smaller of it and kern.maxfilesperproc. On a 16 GB Mac mini running macOS 26.4.1, a process with an unlimited soft limit opened 61,437 files and then got errno 24.

How this was checked: all limits and counts were measured on this Mac mini on 2026-09-28 (Mac16,10, 16 GB, macOS 26.4.1 build 25E253) with a Python script that opens /dev/null until it fails, a C setrlimit test built with Apple clang 21.0.0, and two temporary LaunchAgents that were removed afterwards. The Node and claude figures come from children of a wrapper that forced a soft limit of 256. The scale arithmetic comes from XNU tag xnu-12377.121.6; only the 16 GB row was measured. The 37-question census used the Stack Exchange API, searching titles for "too many open files" with the macos or osx tag on Stack Overflow, Super User and Ask Different, and vote counts are from the same day. I did not change kern.maxfiles or kern.maxfilesperproc on this machine.