Bundled ugrep allocates 4-17 GB to search a 64 KB file when the pattern has a trailing `.{N}` bound (Linux/WSL2, 2.1.214)

Summary

The Grep tool runs the ugrep engine bundled inside bin/claude.exe. On a
regular expression that combines a trailing bounded repetition .{N} with a
variable inner bound .{0,M}, that engine allocates memory at a steady
~230 MB/s for tens of seconds before answering.

Two measured cases, both on inputs of about 64 KB:

| pattern | peak RSS | wall time |
|---|---|---|
| (alpha .{0,40}beta\|gamma).{50} (minimal) | 4.35 GB | 25 s |
| the production pattern below | 17.2 GB (sampled) | not measured to completion |

GNU grep answers the same queries in about 4 milliseconds using a few MB.

This is not an unbounded leak. The allocation is finite and proportional to the
compiled pattern, and the process does terminate once it gets the memory it
wants. The problem is the size of that appetite: on a machine that cannot supply
it, the process thrashes against the limit or the kernel OOM killer fires. A
64 KB haystack containing no match at all should not cost gigabytes.

The patterns come from the assistant, not from the user, so there is no habit a
user can change to avoid it.

Environment

• Claude Code 2.1.214, npm global install

(~/.npm-global/lib/node_modules/@anthropic-ai/claude-code/bin/claude.exe)

• Ubuntu on WSL2, kernel 6.18.33.2-microsoft-standard-WSL2
• WSL VM capped at 48 GB, 8 GB swap

What was observed

An RSS watchdog caught the process while it was still alive and recorded:

{"pid": 28565, "comm": "claude.exe", "rss_gib": 17.23,
 "cmdline": "ugrep -G --ignore-files --hidden -I --exclude-dir=.git [...] -o -i -E .{200}(listow[a-z]* .{0,40}wymiar|wymiar.{0,60}listow|[...]).{200} /tmp/[...]/[redacted].txt",
 "parent_chain": "bash(28563) <- bash(28531) <- claude(6474) <- [...]"}

The input file was 69,799 bytes. This particular process was not OOM-killed:
by then the VM had 47 GB free, and it exited on its own.

Two earlier incidents on the same machine are what prompted the watchdog. Both
were claude.exe processes of the same magnitude, both exhausted a 20 GB VM
along with 8 GB of swap, and both were killed by the kernel:

Jul 16 23:01  Killed process 586284 (claude.exe) anon-rss:16675392kB   # CLI 2.1.211
Jul 18 14:12  Killed process  12378 (claude.exe) anon-rss:16054656kB   # CLI 2.1.214

Their cmdlines were not captured, so tying them to this same Grep pattern is
inference from the matching process name and size, not proof. The 17.2 GB
measurement above stands on its own regardless.

Note the process name: comm is claude.exe because the binary is multi-call
and dispatches on argv[0]. Anyone looking at a runaway "claude" process in
dmesg will see the CLI's own name and reasonably conclude the CLI is leaking.
That is what happened here, and it sent the investigation in the wrong direction
for two days. Recording the cmdline is what turned it around.

Growth curve

Minimal pattern, 64 KB file, under a 10 GB cgroup cap
(systemd-run --user --scope -p MemoryMax=10G), sampling RSS once per second:

t(s)   RSS(MiB)
   1        324
   5       1357
  10       2520
  15       3407
  20       4117
  23       4350   <- peak
  25       process exits, no match found

Linear at ~230 MB/s until the compiled pattern is satisfied, then it answers.
Reproduced twice with peaks of 4330 and 4350 MB.

The cap size decides what failure looks like. Under a 3 GB cap the same run
never completed in 20 seconds: it sat pinned at the cap, thrashing, because the
memory it wanted was not available. That is the shape a user sees on a machine
with less RAM than the pattern demands.

Minimal reproduction

Self-contained, no private data. Generate 64 KB of filler with no match in it:

python3 -c "
import pathlib
line = 'the quick brown fox jumps over the lazy dog 0123456789 '
pathlib.Path('synth.txt').write_text((line * 20 + chr(10)) * 60)
"

CLAUDE_BIN=~/.npm-global/lib/node_modules/@anthropic-ai/claude-code/bin/claude.exe

# Peaks at ~4.3 GB and takes ~25s. Keep the cap: on a smaller machine this is
# the difference between a slow grep and a dead login session.
systemd-run --user --scope -p MemoryMax=10G \
  bash -c "exec -a ugrep $CLAUDE_BIN -i -E '(alpha .{0,40}beta|gamma).{50}' synth.txt"

The recorded production argv reproduces it too, including the -G and the
--exclude-dir flags that the Bash tool's grep shim prepends. In a Bash tool
session grep is a shell function that runs
exec -a ugrep "$CLAUDE_CODE_EXECPATH" -G --ignore-files --hidden -I --exclude-dir=... "$@",
so an ordinary grep call from the model lands on this engine. That is how it
was hit in practice, twice.

One caveat for anyone verifying this: timeout 15 grep ... does not exercise
the shim, because timeout execs a binary and shell functions are invisible to
it. That silently falls back to system grep and looks like the bug does not
reproduce. Use exec -a ugrep against the binary directly, as above.

Which part triggers it

All cases below use the same 64 KB file, under a 4 GB cap. ok means it
finished in under a second; BLOWUP means it was still allocating when killed
at 12 seconds, having already taken gigabytes.

ok      (alpha .{0,40}beta|gamma)                    inner bound alone
ok      .{200}(alpha .{0,40}beta|gamma)              leading pad only
BLOWUP  (alpha .{0,40}beta|gamma).{50}               trailing pad only
BLOWUP  .{50}(alpha .{0,40}beta|gamma).{50}
ok      .{25}(alpha .{0,40}beta|gamma).{25}          outer bound too small
ok      .{200}(alpha .{0,30}beta|gamma).{200}        inner bound too small
ok      .{200}(alpha .{0,20}beta|gamma).{200}
BLOWUP  .{200}(alpha .{0,40}beta).{200}              alternation not required
ok      .{200}(alpha|beta|gamma).{200}               inner bound required

So it needs a trailing .{N} with N of roughly 50 or more, and a
variable inner bound .{0,M} with M of roughly 40 or more. A leading bound on
its own never triggered it in any test. An alternation is not required.

-o is not required either: (alpha .{0,40}beta|gamma).{50} with only -i -E
allocates just the same.

Comparison with GNU grep

GNU grep 3.12 (Debian package grep, invoked as /usr/bin/grep to bypass the
shim) handles both patterns on the same files instantly, exit 1, no match:

/usr/bin/grep -o -i -E '(alpha .{0,40}beta|gamma).{50}' synth.txt
/usr/bin/grep -o -i -E '.{200}(listow[a-z]* .{0,40}wymiar|[...]).{200}' [redacted].txt

Same patterns, same files, same semantics. The difference is the engine.

Impact

When this fires on a machine where the VM is smaller than the allocation, the
kernel OOM killer runs, user@1000.service dies with Result: resources, and
every new terminal tab exits instantly. On WSL the only way back is
wsl --shutdown from PowerShell, which kills every running session.

Suggested fixes

Either would be enough on its own:

1. Bound the engine's memory and fail the Grep call instead of allocating until

the kernel intervenes. A failed grep is recoverable; a dead user session is
not.

1. Stop emitting patterns of this shape from the Grep tool. Context around a

match is what -A, -B and -C are for, and they do not carry this cost.

Related

Possibly the same root cause as #76185 (Linux, 10-15 GB anon RSS, same OOM
signature). That report attributes the growth to idle headless sessions with
background Bash tasks. If those sessions were also running Grep, the trailing
.{N} pattern shape is worth checking before treating them as separate bugs.

.{0,150}brand.{0,150}     -> 18.3 GB RSS, still climbing when killed
.{0,120}mention.{0,120}   ->  8.6 GB RSS and rising, killed at 16.3 GB

BLOWUP  .{0,150}brand.{0,150}     variable bound both sides
BLOWUP  .{0,100}brand.{0,100}
BLOWUP  .{0,60}brand.{0,60}
ok      .{0,40}brand.{0,40}       below the threshold
ok      brand.{0,150}             trailing variable bound alone
ok      .{0,150}brand             leading variable bound alone
ok      .{150}brand.{150}         fixed width both sides

grep -oE '[^"]*\.exe[^"]{0,120}' <a 1,281,005 B JSONL file with very long lines>

13:50:01Z  820 MB   (first sample after the recursive grep at 13:49:58.8Z)
13:50:06Z  1,721 MB
13:50:11Z  2,556 MB          ~90 MB/s ramp
13:53:51Z–13:55:24Z  MemAvailable 78–140 MB, SwapFree 9,707 MB -> 65 MB
13:55:24Z  last sample before the box stopped scheduling
14:45:35Z  one final sample: MemAvailable 29 MB, SwapFree 0
           unresponsive until a hard reboot at ~22:57Z — 9 h 13 m of downtime

ugrep -G --ignore-files --hidden -I --exclude-dir=.git --exclude-dir=.svn --exclude-dir=.hg
      --exclude-dir=.bzr --exclude-dir=.jj --exclude-dir=.sl -oE <pattern> <file>