Not really a solution but a workaround for any Java/JVM based application. -XX:-MaxFDLimit We used the workaround communicated here with the 13.5 update. However, with 14.1 this no longer works an SIP is preventing anything to change that. Our IDEs and our JVM based app has thousands of jar files in the classpath so it's easy to **** the limit. But the defaults in 14.1 seem to be actually ok: ❯ ulimit -Sn && ulimit -Hn && launchctl limit maxfiles unlimited unlimited maxfiles unlimited unlimited (Can someone please confirm these are the defaults in 14.1?) The problem seems to be in the JVM and the documentation setrlimit(2). When passing -XX:-MaxFDLimit to the JVM (whether it's Eclipse, IntelliJ or our own application) we no longer run into any too many open files issues. The problem seems to be this little code snippet: #ifdef __APPLE__ // Darwin returns RLIM_INFINITY for rlim_max, but fails with EINVAL if // you attempt to use RLIM_INFINITY. As per setrlimit(2), OPEN_MAX must // be used instead nbr_files.rlim_cur = MIN(OPEN_MAX, nbr_files.rlim_cur); #endif It's following the advice from setrlimit(2) but I'd argue it's a bad advise in our case. Instead I believe the code should check whether nbr_files.rlim_cur == RLIM_INFINITY and not attempt to call setrlimit at all. The process seems to have enough. Thus, instructing the JVM to not do anything with process file limits (-XX:-MaxFDLimit) solves our "too many open files" problems in Java applications.