Headless run: unbounded recursive directory listing can OOM the machine when bash is blocked (v0.71.1)

Summary

In a headless jcode run session (v0.71.1, dd8755f7e, macOS arm64), when a bash tool call is refused by jcode's own protected-path gate, the model falls back to the built-in recursive file-tree tool. That tool appears to have no depth or output-size cap and buffers the entire listing in process memory.

What happened

• The session was spawned by an automation with working_dir: "/" (inherited from a launchd service — our fault, since fixed).
• First bash call was blocked: "targets a protected system or home path" (target: /Users/<user>).
• The assistant fell back to the tree-listing tool over the home directory (~600 GB of files incl. Library, app bundles, node_modules).
• The jcode process grew to 26.2 GB RSS in ~15 minutes on a 24 GB machine and contributed to a kernel watchdog panic (WindowServer starved; artifact: macOS panic-full report). The session journal stops mid-listing while the process kept growing.

Suggested fixes

1. Cap the recursive tree tool (depth limit, entry limit, and/or total-bytes limit with truncation marker) — same spirit as CLI tools that truncate large reads.
2. Consider refusing to tree-walk /, $HOME, and other protected roots with the same gate that blocks bash against them (currently the gate blocks the safe read-only ls via bash but the built-in tool happily walks the same path unbounded).
3. Optionally: a process-level memory ceiling for headless runs.

Happy to provide the session journal (redacted) if useful.

Start with the built-in recursive file-tree tool and the protected-path gate used by headless jcode run; reproduce the behavior with a session whose working_dir is / and whose bash access is blocked. Done means large or protected-root listings no longer grow without bounds, with a clear truncation or refusal behavior, and the regression is covered by an appropriate test.