[rhishi99]

Problem

When binary resolution through PATH fails, RTK falls back to a direct exec and prints a note to stderr:

rtk: Failed to resolve 'x' via PATH, falling back to direct exec: ...

In a terminal that is a useful signal. Inside an agent it is the opposite:

• The command still ran. Nothing failed.
• On Windows the agent merges stderr into its context, so the note lands in the prompt.
• A diagnostic about a command that worked costs more tokens than the filter saved.

Not spending those tokens is the entire point of the project.

Fix

Two opt-ins, both default off:

$env:RTK_QUIET = '1'

[hooks]
quiet = true

Informational stderr is suppressed; real errors are untouched. Existing users see no change.

Performance note

The config lookup is cached in a OnceLock. Config::load() re-reads and re-parses the file on every call, and this sits on the command-resolution path — reading it uncached would put file I/O on the critical path the project explicitly keeps clear ("no config file I/O on the critical path"). With the cache, the cost is one read per process, only when a PATH lookup actually falls back.

Testing

test_hooks_quiet_defaults_off_and_deserializes pins all three cases: default off, quiet = true parses, and a config predating the field still parses. The suppression itself is a single !quiet && guard on an existing branch, gated on env/config that a unit test cannot mutate without racing other tests.

Docs added to docs/guide/getting-started/configuration.md.

Full suite on x86_64-pc-windows-gnu: 2615 passed. cargo fmt --check and cargo clippy --all-targets clean. The single unrelated failure on this toolchain is fixed in #3615.

🤖 Generated with Claude Code

[CLAassistant]

All committers have signed the CLA.