Error: rtk find does not support compound predicates or actions

[sanjaynagi-eit]

"Error: rtk find does not support compound predicates or actions (e.g. -not, -exec). Use find directly."

probably not good for token usage!

[lpsm-dev]

Technical Analysis

Environment

• rtk 0.28.2, macOS (Darwin 25.3.0)
• Claude Code with rtk-rewrite.sh hook (v2)
• Hook delegates all rewrite logic to rtk rewrite

Root Cause

The rtk rewrite command (Rust registry in src/discover/registry.rs) rewrites find commands to rtk find without checking whether the command contains predicates/actions that rtk find does not support. When executed, rtk find correctly rejects these but the error is emitted at execution time, not at rewrite time.

This means:

1. Claude Code hook calls rtk rewrite "find . -name '*.md' -not -path './node_modules/*'"
2. rtk rewrite returns rtk find . -name '*.md' -not -path './node_modules/*' (rewrites it)
3. Hook applies the rewrite (since rtk rewrite returned success)
4. rtk find fails with: Error: rtk find does not support compound predicates or actions (e.g. -not, -exec). Use find directly.
5. The AI agent sees the error, wastes tokens, and may retry

Unsupported predicates (observed)

-not, -exec, -execdir, -ok, -okdir, -delete, -prune, -fls, -fprint, -fprintf, -quit

Impact

• Token waste: error message + retry = ~200-500 tokens per occurrence
• Breaks automated workflows where find with compound predicates is common (e.g., find . -name '*.pyc' -delete, find . -path './vendor' -prune -o -name '*.go' -print)
• Ironic: a tool designed to save tokens causes token waste

Suggested Fix

The fix should be in rtk rewrite, not in the hook. When rtk rewrite receives a find command containing any unsupported predicate/action, it should not rewrite (exit 1 / return the original command), letting the native find execute directly.

Pseudo-logic:

// In registry.rs, find rewrite rule
const UNSUPPORTED_FIND_PREDICATES: &[&str] = &[
    "-not", "-exec", "-execdir", "-ok", "-okdir", 
    "-delete", "-prune", "-fls", "-fprint", "-fprintf", "-quit"
];

fn should_rewrite_find(args: &[&str]) -> bool {
    !args.iter().any(|arg| UNSUPPORTED_FIND_PREDICATES.contains(arg))
}

Current Workaround

Added a pre-check in the Claude Code hook (~/.claude/hooks/rtk-rewrite.sh) that skips rewrite for find commands containing unsupported predicates:

# Guard: rtk find does not support compound predicates/actions.
if echo "$CMD" | grep -qE '^\s*find\s' && \
   echo "$CMD" | grep -qE '\s-(not|exec|execdir|ok|okdir|delete|prune|fls|fprint|fprintf|quit)\s'; then
  exit 0
fi

This works but is fragile (duplicates knowledge of what rtk supports) and should not be necessary if rtk rewrite handles it correctly.

[lpsm-dev]

Proposed Fix (based on source code analysis)

Root Cause in Code

The bug is a check-at-wrong-layer problem. The unsupported flag validation exists in src/find_cmd.rs (execution time) but is missing from src/discover/registry.rs (rewrite time).

Flow today:

find . -not -name foo
  → registry.rs: classify_command() matches ^find\s+ → Supported
  → registry.rs: rewrite_segment() replaces "find" → "rtk find" (exits 0)
  → hook applies rewrite → "rtk find . -not -name foo"
  → find_cmd.rs: has_unsupported_find_flags() detects -not → bail! (error)
  → original `find` NEVER runs

Relevant Source Locations

File	Function	Issue
src/discover/rules.rs	PATTERNS[9]	Regex ^find\s+ matches all find commands indiscriminately
src/discover/registry.rs	classify_command()	No find-specific flag check (only has cat/head/tail redirect guard)
src/discover/registry.rs	rewrite_segment()	No find-specific guard (only has rtk gh --json/--jq guard)
src/find_cmd.rs	has_unsupported_find_flags()	Correct validation, but at wrong layer (too late)
src/find_cmd.rs	UNSUPPORTED_FIND_FLAGS	Authoritative list of unsupported flags

Suggested Fix

Option A — Guard in rewrite_segment (minimal, consistent with existing gh guard pattern):

In src/discover/registry.rs, add a find-specific guard in rewrite_segment, after the existing rtk gh guard:

// After the existing gh --json/--jq guard, add:
if rule.rtk_cmd == "rtk find" {
    use crate::find_cmd::UNSUPPORTED_FIND_FLAGS;  // reuse, don't duplicate
    let args: Vec<&str> = cmd_clean.split_whitespace().skip(1).collect();
    if args.iter().any(|a| UNSUPPORTED_FIND_FLAGS.contains(&a)) {
        return None;  // fall back to native find
    }
}

This requires making UNSUPPORTED_FIND_FLAGS public in find_cmd.rs:

// src/find_cmd.rs — change from:
const UNSUPPORTED_FIND_FLAGS: &[&str] = &[...];
// to:
pub const UNSUPPORTED_FIND_FLAGS: &[&str] = &[...];

Option B — Guard in classify_command (architecturally cleaner):

The cat/head/tail redirect guard already lives in classify_command. Adding the find guard there keeps all "should we rewrite?" logic in one place:

// In classify_command, after the redirect guard for cat/head/tail:
if idx == 9 {  // find — or better: match by rule.rtk_cmd == "rtk find"
    use crate::find_cmd::UNSUPPORTED_FIND_FLAGS;
    let args: Vec<&str> = cmd_clean.split_whitespace().skip(1).collect();
    if args.iter().any(|a| UNSUPPORTED_FIND_FLAGS.contains(&a)) {
        return Classification::Unsupported {
            reason: "find with compound predicates".into(),
        };
    }
}

Option C — Generic "pre-flight" check (future-proof):

Add a can_handle(args) trait/method to each command module. Before rewriting, call FindCmd::can_handle(args). This scales if other commands (e.g., grep) have similar unsupported-flag issues, but it's more invasive.

Recommendation

Option A is the smallest change with zero risk. It reuses the existing constant, follows the established pattern (the gh guard is identical in structure), and the fix is 6 lines of Rust.

Option B is cleaner architecturally but touches classify_command which is a hotter path.

Option C is the right long-term design but overkill for this bug.

[TechWizard9999]

I’m taking this issue. I’ll update rewrite behavior so unsupported compound find predicates/actions are passed through (not rewritten), with tests, in a focused PR against develop.

[TechWizard9999]

I’ve submitted a PR to address this issue: #676

Changes include:

• skipping rewrite for find commands with unsupported compound predicates/actions
• preserving native find execution for patterns like -not, -exec, -prune, etc.
• adding regression tests for unsupported find rewrite cases

Validation run:

• cargo fmt --all --check
• rtk cargo clippy --all-targets
• rtk cargo test

Please review when you get a chance.

[pszymkowiak]

wshm · Automated triage by AI

🔍 Automated Triage

🐛 Category	bug
🟡 Priority	medium
🎯 Confidence	85%

Summary

rtk find errors on compound predicates (-not, -exec) causing fallback to native find and increased token usage; two PRs already in progress to fix rewrite grammar filtering.

This looks like a simple fix that could be auto-resolved. Repo maintainers can use /wshm fix to attempt it.

---

Triaged automatically by wshm · This is an automated analysis, not a human review.

[meiazero]

Still reproducing on rtk 0.40.0 — rtk rewrite rewrites a compound find to rtk find …-exec, which rtk find then rejects at runtime, so the command fails once before any fallback.

Repro

$ rtk --version
rtk 0.40.0

$ rtk rewrite 'find . -type f -exec wc -l {} +'
rtk find . -type f -exec wc -l {} +
# exit 3

$ rtk find . -type f -exec wc -l {} +
rtk: rtk find does not support compound predicates or actions (e.g. -not, -exec). Use `find` directly.
# exit 1

Why it matters under the Claude Code hook

rtk rewrite returns exit 3 (rewrite + ask), so the PreToolUse hook applies the rewrite. rtk find then fails, and the agent has to retry with plain find. Every compound find …-exec costs one failed invocation.

PR #676 (fix(rewrite): skip unsupported find predicates) appears to address this at the right layer — having rtk rewrite return exit 1 (passthrough) for compound predicates so the hook leaves find untouched.

---

_{Report generated by Claude Code using Claude Opus 4.7 (1M context).}

[danmunoz]

Submitted a PR #2014 addressing this issue with a slight different approach, where some "dangerous" actions are filtered but letting all others pass through.