find→bfs rewrite has no search-root guard: unscoped path resolution triggers a full-disk (/) scan, pegging CPU

Summary

The Claude Code PreToolUse hook (rtk hook claude) rewrites find invocations into bfs. When the rewritten command's search-root path argument resolves incorrectly (e.g. a relative/missing path in an agent-issued command), the rewrite falls through to a filesystem-root scan (bfs -S dfs -regextype findutils-default / -path */gh-aw/* -iname *.cjs) instead of failing fast or refusing to scope wider than cwd/repo root. On macOS this pegged claude.exe (the rtk-hooked CLI process) at 400%+ CPU for an extended period, scanning the entire disk, until manually killed (pkill/kill <pid>).

Repro context

• rtk 0.37.2, installed at /opt/homebrew/bin/rtk, hooked via ~/.claude/settings.json:

  {"matcher": "Bash", "hooks": [{"type": "command", "command": "rtk hook claude"}]}
  

• Triggered by a Claude Code background agent job attempting to locate a .cjs file under a gh-aw-related path. The intended search was scoped to a specific directory tree, but the rewritten bfs invocation ended up rooted at /.
• ~/Library/Application Support/rtk/history.db has no record of the runaway command — it appears rtk only logs a command after it completes, so a killed/never-finished scan leaves no trail. This makes the failure mode hard to audit after the fact (can't tell how often it's recurred).

Expected behavior

find→bfs rewrite should refuse (or at minimum warn loudly) when the resolved search root is / or another filesystem root, rather than silently launching a full-disk scan. Ideally the search root should be validated/clamped to cwd or the resolved repo root before rewrite, with an explicit opt-out for genuinely full-disk searches.

Possibly related

[limits] config section appears to be a natural place to add a safety knob for this (e.g. find_max_depth / a search-root allowlist), but per #3368, the [limits] section currently has defects that make it unreliable even for its existing documented keys:

• grep_max_results is declared/defaulted/printed but never actually read anywhere in the code (only grep_max_per_file is wired up).
• A partial [limits] section fails TOML deserialization for the entire config, silently reverting every other section (including [hooks]) to defaults.

Worth fixing #3368 first (or in tandem) if a [limits]-based root-scoping guard is the intended fix here, otherwise the new setting risks the same "silently ignored" failure mode.

Environment

• macOS (Darwin), rtk 0.37.2
• Claude Code CLI, background job / bg-spare daemon process

Start at the rtk hook claude PreToolUse rewrite path and trace how the search-root argument becomes the bfs root. Reproduce the relative or missing-path case from the issue, then inspect the [limits] configuration behavior and issue #3368 before choosing a guard. Done means root-level scans are refused or loudly warned, normal scoped searches still work, and any new setting is not silently ignored.