File Starting With Dash: rm * Deleted a Folder, Exit 0

On 2026-09-25 I counted my own Claude Code transcripts with grep -l compact_boundary */*.jsonl and got an empty result, which I started writing into a draft as "zero sessions". Rerun today on the same folders, the right answer is 9 files out of 1,638. Every directory under ~/.claude/projects is named after a path, so every one of them starts with a dash: -Users-sg-mini-GitHub-mmm. grep did not read those as files. It read them as flags.

The usual advice for a file starting with a dash is two lines long: put -- before it (POSIX Guideline 10 makes it the end-of-options marker), or write ./ in front. Both are correct. What the advice leaves out is when you get an error and when you get a wrong answer with exit 0. I reran the problem in a scratch directory on this Mac mini (macOS 26.4.1, bash 3.2.57, zsh 5.9) with the stock BSD tools and with GNU coreutils 9.12 from Homebrew. The answer depends on the letters in the name, on which command you run, and on your locale.

How a directory name became a grep pattern

BSD grep reads -Users-sg-mini-GitHub-mmm/a.jsonl as a bundle of single-letter options. -U is binary mode. -s suppresses error messages about missing files. -e takes an argument, and the rest of the word becomes that argument. So the path turned into the search pattern, and my real pattern, compact_boundary, turned into a filename.

I checked this reading directly. With a file called needle in the working directory containing the text rs-sg-mini-proj/a.jsonl, the command grep -l needle -Users-sg-mini-proj/a.jsonl prints needle and exits 0. That is a false positive that looks exactly like a real hit.

The silence is luck of the alphabet. Today, when I widened the glob to all 104 project directories, the same command failed loudly with grep: invalid option -- t. 86 of those directories come from probe sessions under /private/tmp, and -private... reaches the letter t, which BSD grep does not accept. The 18 directories under /Users spell -U -s -e and stay quiet. The only signal left in the quiet case was exit status 2, and my census never looked at it. I no longer have the stderr from the 2026-09-25 run, so I can't say which of the two versions I hit then. That is the same failure as a bash pipe hiding the exit code, one step earlier.

What rm, cat and ls do with a dash file in the glob

Quoting does not help. rm "-foo" and rm \-foo both fail with rm: illegal option -- o and exit 64, because the shell strips the quotes before rm sees anything. Those are the easy cases, since they fail. The glob cases are the ones that succeed:

The -i row is the old trick from the GNU coreutils FAQ: drop a file named -i in a directory so that rm * asks first. In an unattended script with no terminal it does not ask anyone. It quietly deletes nothing and still exits 0, which is a different bug.

Position matters on a Mac, and not on GNU

A comment on the 2014 Hacker News thread about wildcard attacks says that on BSD "the options are passed before the file names", so a stray flag after a filename is harmless. I tested that on this Mac by putting an invalid flag -~ after a real file argument. For 16 commands the claim held: cat ls wc head tail touch chmod rm cp mv ln mkdir sed tar du stat all treated -~ as a filename. Four did not: grep, sort, diff and file rejected it as an option. Those use getopt_long, and the FreeBSD getopt_long man page says its default is "to permute non-option arguments to the end". That is why grep ate a path that sat after the pattern. All 7 GNU coreutils I tried (gcat gls gwc ghead grm gcp gtouch) rejected it too. glibc's getopt permutes by default unless POSIXLY_CORRECT is set.

Position then depends on sort order, and sort order depends on locale. With five names, +plus -rf abc zeta sub/, bash and zsh both expand * as +plus -rf abc sub zeta under LC_ALL=C and as -rf +plus abc sub zeta under en_US.UTF-8 and ko_KR.UTF-8. Same directory, same rm *:

The Mac was safe in one row out of the five, and only because an unrelated file happened to sort first. In an ordinary directory with no + names, the dash file came first in all three locales I tried. I would not count the BSD ordering as protection.

find on macOS does not take --

The fix I reached for on the census was find, and it worked because find . prints paths as ./-Users-sg-mini-GitHub-mmm/.... The ./ prefix protects everything downstream. Naming a dash directory directly is different. /usr/bin/find -Uproj fails with illegal option -- U, and so does find -- -Uproj: the Mac find prints its usage block for the double dash too. The macOS form is find -f -Uproj -- -name '*.jsonl'. The find(1) man page documents -f for paths that begin with "!", "(" or "-". It then prints -Uproj/a.jsonl, which starts with a dash again for the next command in the pipe.

-- is not universal elsewhere either. echo -- x prints -- x in both bash and zsh. The famous 2014 Unix Wildcards Gone Wild paper used files named --checkpoint-action=exec=... against tar. The Mac's bsdtar 3.5.3 answers Option --checkpoint=1 is not supported, so that particular payload is a GNU tar problem. The rm and grep rows above are not.

What I changed

# globs in scripts always get a path prefix
rm ./*
grep -l compact_boundary ./*/*.jsonl

# or end option parsing where the command supports it
grep -l compact_boundary -- */*.jsonl

# find on macOS: -f for a dash path, and . for everything else
/usr/bin/find -f -Uproj -- -name '*.jsonl'
find . -name '*.jsonl' -print0 | xargs -0 grep -l compact_boundary

# a single file
rm -- -foo
rm ./-foo

I prefer ./ over -- in scripts, for the reason in ShellCheck SC2035. It works for every command, including the ones that treat -- as data. The other rule is older and cheaper: a census that returns zero gets its exit code checked before the zero goes anywhere. grep's 0, 1 and 2 are three different answers, and on 2026-09-25 I read a 2 as a 1.

This belongs with sed invalid command code, where a filename was also read as part of the command, and with xargs on macOS. When I run these tests inside Claude Code, the shell's grep is a wrapper, as I found in Claude Code grep skips gitignored files, so every grep result here used command grep, which is /usr/bin/grep. The census that started this is in Claude Code /compact vs /clear.

For the question itself I checked the two canonical Unix Stack Exchange threads through the Stack Exchange API. How do I delete a file whose name begins with a hyphen has 522 votes, 234,087 views and 10 answers. Why doesn't rm * work when there are files that begin with a hyphen has 2 more. None of the 12 answers mentions argument order, locale, BSD or macOS. The fixes in them are right. They just don't say when you would find out that you needed one.

Sources: all results were measured on 2026-09-29 on a Mac mini (Mac16,10, macOS 26.4.1 build 25E253) in a scratch directory under /tmp, using /usr/bin/grep (BSD grep 2.6.0-FreeBSD), /usr/bin/find, the stock rm, cat and ls, bsdtar 3.5.3, and GNU coreutils 9.12 from Homebrew for comparison. The transcript figures (104 directories, 1,638 files under the 13 home-directory projects, 9 matches) come from my own ~/.claude/projects on the same day. The option-parsing rules are quoted from POSIX Utility Syntax Guideline 10, the glibc and FreeBSD getopt documentation, and the macOS rm and find man pages. Stack Exchange vote and view counts were read from the Stack Exchange API, and the Hacker News comment was read through the Algolia items API.