Fixing the 'Too many open files' (EMFILE) Error on macOS

The Error Message

You’re in the middle of a heavy build or starting up a local database when everything suddenly grinds to a halt. Your terminal throws a wall of text, usually peaking with this line:

Error: EMFILE: too many open files, open '/path/to/your/project/file.js'

Sometimes, the error is even more cryptic, refusing to let you change settings manually:

ulimit: open files: cannot modify limit: Invalid argument

The Root Cause: macOS Safety Breaks

Out of the box, macOS is surprisingly stingy with file descriptors. It often caps a single process at just 256 or 1,024 files. While that was plenty a decade ago, modern development is much more resource-intensive.

Consider a standard Next.js or Vite project. A single npm install can pull in over 30,000 files across the node_modules directory. When your compiler tries to index these files simultaneously, it hits that 1,024 ceiling almost instantly. The operating system steps in, kills the request, and triggers the EMFILE error to protect system resources.

Solution 1: The Quick Fix (Current Terminal Only)

If you just need to finish a build right now, you can bump the limit for your active terminal tab. This change is temporary and will vanish the moment you close the window.

Check your current restriction first:

ulimit -n

If the output is 256 or 1024, it's too low. Run this command to raise the limit to 65,536 for this session:

ulimit -n 65536

Try running your build again. It should now have enough breathing room to complete without crashing.

Solution 2: Make it Permanent for your Shell

Most macOS users run Zsh. To avoid running the ulimit command every time you start work, add it to your shell configuration profile.

• Open your configuration file:

nano ~/.zshrc

• Paste this line at the very bottom:

# Boost max open files for development
ulimit -n 65536

• Save and exit by pressing Ctrl + O, Enter, then Ctrl + X.
• Force the changes to take effect:

source ~/.zshrc

Solution 3: The System-Wide Fix (Recommended)

Shell tweaks won't help if your IDE (like VS Code) or a background service (like MongoDB) is the culprit. These applications don't always inherit settings from your .zshrc. To fix this at the kernel level, you need to use launchctl.

Follow these steps to create a persistent system configuration:

• Create a new system-level configuration file:

sudo nano /Library/LaunchDaemons/limit.maxfiles.plist

• Insert the following XML code. This sets a "soft" limit of 64k and a "hard" system limit of 512k:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>Label</key>
  <string>limit.maxfiles</string>
  <key>ProgramArguments</key>
  <array>
    <string>launchctl</string>
    <string>limit</string>
    <string>maxfiles</string>
    <string>65536</string>
    <string>524288</string>
  </array>
  <key>RunAtLoad</key>
  <true/>
  <key>ServiceIPC</key>
  <false/>
</dict>
</plist>

• Secure the file permissions so the system accepts it:

sudo chown root:wheel /Library/LaunchDaemons/limit.maxfiles.plist
sudo chmod 644 /Library/LaunchDaemons/limit.maxfiles.plist

• Load the new settings:

sudo launchctl load -w /Library/LaunchDaemons/limit.maxfiles.plist

• Restart your Mac. A full reboot ensures these kernel-level changes apply to every app you open.

Verifying the Results

Once you've rebooted, verify that the new limits are active. Open a fresh terminal and run:

launchctl limit maxfiles

You should see 65536 and 524288 in the output. If the numbers are still low, double-check the XML syntax in your .plist file.

Prevention and Best Practices

• Manage Watchers: Tools like nodemon or chokidar use file watchers to detect changes. If you leave five different projects running, they’ll quickly exhaust your quota. Close what you aren't using.
• Audit node_modules: Ensure your IDE isn't trying to index the entire node_modules folder for search results. Most modern editors exclude this by default, but it's worth checking your settings.
• Clean Up Connections: If you're writing custom scripts, always close your file streams and database connections. Even a 65k limit won't save you from a memory leak that keeps descriptors open indefinitely.