[chaliy]

What changed

• New stress test binary (large_tree_stress_tests) runs walkers over a procedural tree (default 20k files, just stress = 2M files) with a counting allocator and asserts peak memory stays bounded: find, find|wc, du, tree -L 2, grep -rl, ls -R, rg.
• rg walks a single root in path order and reads files as it finds them, instead of building the whole candidate list first. It stops reading once the input budget is spent.
• ls -R stops producing output once it passes the stdout limit, instead of building the full listing and truncating it afterwards.
• Knowledge: testing.md, threat model TM-DOS-140 rows (knowledge + public), vfs.md, log.md.

Why

Last part of the remote FS walk work: prove that a repo with millions of files can't push bashkit into unbounded memory.

Before / After

At 2M files (just stress, release):

command	before	after
find / du / tree / grep -r	0.2–2.3 MiB peak	unchanged
ls -R	35.4 MiB	~7 MiB (capped at the stdout limit)
rg over budget (1 MiB budget)	~70 MB peak	~14 MB, reads stop early
rg within budget (200k files)	66 MB	34 MB

Known gap: rg within budget still keeps all searched text (158 B/file). Fixing it needs a streaming search; this is marked as TODO(TM-DOS-140) in the test and the docs.

Risk

• Low/Medium. rg's file order and output are unchanged (still sorted by path). ls -R output is unchanged below the stdout limit.

Checklist

• Tests added or updated
• Backward compatibility considered

---

Generated by Claude Code

---

^{Open in [code]smith · Need help on this PR? Tag @codesmith-bot with what you need.}

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	bashkit	bb10f8a	Commit Preview URL Branch Preview URL	Nov 03 2026, 07:04 AM

[bashkit-pr-reviewer]

Good mitigation, well-pinned by tests. Two gaps, one in the ls cap's granularity and one residual in rg's collect path. No P0.

[bashkit-pr-reviewer]

Review summary — #2820 (head bb10f8ad, 3rd push)

Verdict: The P1 is fixed: per-line output_limit breaks now guard every append loop (-l, one-per-line, and subdir headers), plus a ls_wide_directory_stops_at_the_stdout_limit regression test. Posted one new P2 on the narrowed residual; the rg multi-root P2 from before still stands.

Findings:

• [P1, resolved] ls per-line cap — verified the new if output.len() > opts.output_limit { break; } checks in each loop and the wide-dir test (-l, -1, explicit paths).
• [P2, new] names Vec / format_columns still unbounded (ls/list.rs:433): the non-long branch collects every entry name before the (now capped) output loop, and column mode formats the whole grid in one push — a wide dir in the default path still transiently holds ~50+ B per entry.
• [P2, still open] rg multi-root / non-path sorts still collect-then-read (rg/mod.rs:3092): unchanged this push.

Context this round: refreshed checkout, confirmed rg/docs/stress hunks are untouched since the last head and the only implementation delta is the per-line ls breaks; read the new regression test. Still not built/run (no cargo in this shell).

[bashkit-pr-reviewer]

Per-line caps look right and the wide-dir regression test covers -l/-1. One narrowed residual of the same issue remains in the non-long branch.