Zsh Argument List Too Long: 45,524 Names Fit, Not 100,000

I made 100,000 empty files named like IMG_000123.jpg on this Mac mini and typed ls *. zsh answered zsh:1: argument list too long: ls and exited 127. echo * in the same directory printed all 1,500,000 bytes of names without complaint. Both commands saw the same glob. Only one of them had to go through exec, and on macOS exec has a fixed budget of 1,048,576 bytes that you cannot raise.

The message comes from the kernel, not from zsh. zsh expands the glob fine; the error happens when it hands the list to a separate program. I measured where the line sits on macOS 26.4.1, what counts against it besides your file names, and timed six ways around it on the same 100,000 files. I also pulled the 283 Stack Exchange questions with "argument list too long" in the title to see which cases Mac and zsh users actually hit.

What the error means

The execve() system call returns E2BIG when the arguments plus the environment do not fit. Each shell words it differently, which matters when you search for it:

zsh reports 127, the same code as "command not found", so a script that checks for 127 can misread it. Shell builtins never call exec, which is why echo *, print -l *, files=(*) and for f in * all work on a list that ls * refuses. If a glob is what you are fighting, zsh's no matches found error is the other end of the same expansion.

The 1 MiB budget and what it is charged for

$ sysctl kern.argmax
kern.argmax: 1048576
$ getconf ARG_MAX
1048576
$ sysctl -w kern.argmax=2097152
sysctl: oid 'kern.argmax' is read only

In the XNU source for this macOS release, kern.argmax is registered read-only with the compile-time value ARG_MAX, which syslimits.h sets to 1024 * 1024 for macOS. The comment above exec_extract_strings in kern_exec.c states the accounting: "we charge the string length and argv[]/envv[] pointer slot" against that budget. So each argument costs its length, plus one byte for the terminating NUL, plus eight bytes for the pointer.

I checked that with a small C program that calls execve on /usr/bin/true and binary-searches the largest argument count that succeeds:

45,524 times 23 is 1,047,052 bytes. The remaining 1,524 bytes went to the environment, which was 1,234 bytes across 29 variables in this shell, plus its pointers and the program path. So the working rule is: divide 1,048,576 by (average name length + 9), then subtract whatever the environment takes. A **/* glob with long relative paths runs out far sooner than a flat directory; at 60 characters per path the ceiling is about 15,000 files.

Two things that work on Linux do nothing here. Linux derives the limit from the stack size, and the execve(2) man page describes it as a quarter of the stack limit. On this Mac I set ulimit -s to 1,024, 8,176 and 65,520 KB and the count stayed at 45,525 each time. Linux also caps any single string at 32 pages, 128 KiB on 4 KiB pages. macOS has no separate cap: I passed one 1,040,000-byte argument to /bin/echo and it printed.

Your environment spends the same budget

The environment is copied into the same 1 MiB. I exported one variable of increasing size and re-ran the search for 14-character arguments:

This is the version of the error where every command fails, including ls with no arguments, while cd and echo keep working because they are builtins. The most common way to get there is a startup file that grows PATH each time it runs. I reproduced the pattern one answerer on Unix & Linux described, path+=(dir $path), which appends the whole existing path again instead of one directory. Starting from six entries it doubles each round. At round 14 PATH was 1,376,234 bytes and 114,687 entries long and /usr/bin/true failed. Use typeset -U path to keep the array unique, and check env | wc -c before blaming the command.

A script whose shebang points at itself does something similar. This Stack Overflow question quotes env: node: Argument list too long for every node command, and /usr/bin/node in it starts with #!/usr/bin/env node. I made a script named loopy with #!/usr/bin/env loopy, put it first in PATH, and got env: loopy: Argument list too long, exit 126. As far as I can tell from the output, each hop adds the script path again until exec refuses. The fix there is finding which file shadows the real binary with whence -a node. A related exec failure with a different message is zsh's exec format error.

Six ways around it, timed on 100,000 files

Each run started from a fresh directory of 100,000 empty files in /tmp on the internal SSD. Times are wall clock.

Anything that batches is within about two seconds of the fastest. The loop is 30 times slower because it starts one rm per file. The batch sizes come from defaults: macOS xargs stops at 5,000 arguments per call (its man page gives -n a default of 5000 and -s a default of ARG_MAX minus 4096), zsh's zargs function uses -s 20480, and find -exec {} + packs close to the full megabyte.

The zsh-only option is the zsh/files module, which turns rm, mv, ln, mkdir, rmdir, chmod, chown, chgrp and sync into builtins. There is no cp. The zsh manual calls these useful "in emergency recovery situations" and warns they do not implement every standard feature. That warning is real: with the module loaded, chmod +x file failed with invalid mode `+x' because the builtin takes octal only, and rm -v failed with bad option: -v. Loading it in .zshrc would change those commands everywhere. The safer form loads only the prefixed names and leaves the real rm alone:

zmodload -m -F zsh/files b:zf_\*
zf_rm -- *          # 100,000 files, 4.23 s, no exec
zf_mv -- *.log old/ # same idea for moves

For anything that is not a file operation, such as grep, curl, git add or zip, the choice is between find -exec … {} + when the input is files on disk, and print -rN -- … | xargs -0 when the list already exists in the shell. Both use NUL separators, so names with spaces survive. If the tool can read names from a file or stdin itself, as git add --pathspec-from-file=- and tar -T can, that avoids the limit with no batching at all.

What 18 Mac and zsh questions were really about

The Stack Exchange API returned 283 questions with "argument list too long" in the title: 215 on Stack Overflow, 56 on Unix & Linux, 11 on Super User and 1 on Ask Different. I kept the 18 tagged macos, osx or zsh, or with Mac or zsh in the title. One of them is an Arch Linux zsh question, included because the cause is the same.

• 7 were too many file names from a glob or $(…): rm -rf *, a full Trash, ls **/*.js, git rm $(git status …), GNU Parallel with 20,000 inputs. The fixes above cover all of them.
• 4 were the environment or an exec loop, the "every command fails" kind: a duplicated PATH, a large generated .env, the env node shebang loop. None of these is fixed by xargs.
• 2 were one huge argument, such as 50,000 IDs passed through `cat ids.txt`. One was a 1.4 MB string, which cannot fit on macOS at any setting; pass it on stdin or as a file path.
• 5 were tool-specific: codesign, an old Xcode gcc, Java, xattr on a resource fork and mv on a FAT volume.

The Ask Different question asks how to raise the limit on a 64 GB machine. On this macOS the answer is that you can't: the value is a constant in the kernel, not a tunable, and a 2012 answer on Super User quoted 262,144 for Mac OS X 10.7.3, so the number has moved between releases, never through a setting. The same "the knob exists but does nothing" pattern shows up with too many open files on Mac, where ulimit -n unlimited is accepted and then capped by the kernel.

FAQ

How do I fix "zsh: argument list too long" with rm?

Batch the names instead of passing them all to one rm. find . -name 'pattern' -delete is the fastest I measured (3.83 seconds for 100,000 files). In zsh, zmodload -m -F zsh/files b:zf_\* followed by zf_rm -- * deletes them with a builtin that never calls exec. print -rN -- * | xargs -0 rm -- also works.

Can I increase ARG_MAX on macOS?

No. kern.argmax is read-only and fixed at 1,048,576 bytes; sysctl -w reports "oid 'kern.argmax' is read only", and changing ulimit -s does not affect it as it does on Linux. Arguments and environment variables share that budget, and each argument costs its length plus 9 bytes.

Why does every command say argument list too long?

The environment is too big, usually because a startup file appends PATH to itself on every run. Builtins like cd and echo still work because they do not call exec. Check env | wc -c, look for a line like path+=(dir $path), and add typeset -U path to keep entries unique.

How this was checked: every number in this post was measured on this Mac mini on 2026-09-28 (Mac16,10, 16 GB, macOS 26.4.1 build 25E253, zsh 5.9, bash 3.2.57) using a C program built with Apple clang that binary-searches the largest execve that succeeds, and 100,000 empty files in /tmp that were deleted afterwards. The accounting rule comes from XNU tag xnu-12377.121.6 (kern_exec.c, kern_sysctl.c, syslimits.h). The census used the Stack Exchange API on the same day, searching titles for "argument list too long" on Stack Overflow, Unix & Linux, Super User and Ask Different; the categories are my reading of each question. The shebang-loop explanation is inferred from the error, not traced in the kernel.