Feature request: per-invocation escape hatch (flag/env var) so an agent can self-disable rtk rewriting when stuck

Summary

Request: a documented, per-invocation escape hatch that disables RTK's command rewriting/output condensation for a single command — ideally both a CLI flag and an env var — that an LLM agent can set itself when it determines RTK's rewritten output is hiding information it needs.

The motivating case: a Claude/Cursor agent ran npm test (jest), RTK's wrapper condensed the output, and the failing test detail the agent needed wasn't in the rewritten summary. The agent then retried the same command repeatedly with minor variations, getting the same condensed output each time, and got stuck in a loop until a human intervened.

If there were a known, agent-discoverable knob like RTK_PASSTHROUGH=1 npm test or npm test --rtk-passthrough (name TBD), the agent's loop-recovery logic could try it once and get the raw underlying output without the user having to uninstall RTK or reconfigure their shell.

Why a flag/env var (not just "uninstall rtk")

• The whole point of RTK is that it's installed transparently — for humans and for the common agent path it's a net win. An agent shouldn't need to know how RTK was installed (Homebrew? PATH shim? hook?) to bypass it.
• Telling a user "please disable rtk and rerun" is exactly the kind of human-in-the-loop escalation RTK is supposed to reduce. A documented escape hatch keeps the agent unblocked.
• Existing wrappers in this space (e.g. NO_COLOR, CI=1, FORCE_COLOR=0, npm_config_*) have set the precedent that a single env var is the right surface area for tools that an agent might run unattended.

Suggested shape

Any of these would solve it; ranked by how useful they'd be to an agent:

1. RTK_PASSTHROUGH=1 env var — when set, RTK execs the underlying tool directly (or runs as a no-op wrapper that streams stdout/stderr unchanged and propagates exit code). One-shot via RTK_PASSTHROUGH=1 npm test is ideal because it doesn't pollute the parent shell.
2. --rtk-passthrough / --rtk-off CLI flag — RTK strips it from argv before invoking the wrapped tool. Useful when the agent can edit the command but not the env.
3. RTK_DISABLE=jest (or RTK_DISABLE=*) env var — finer-grained: disable rewriting for a specific wrapped command. Helpful for users who want RTK on for tsc but off for jest.
4. Documented exit-code/marker in the rewritten output — e.g. "to see raw output, rerun with RTK_PASSTHROUGH=1" appended to RTK's summary footer. This is what makes it agent-discoverable: the next time the agent reads condensed output and isn't satisfied, the recovery action is right there in the output it just read.

(4) is the cheapest and arguably the highest-leverage piece — without it, agents won't know the escape hatch exists; with it, they'll learn the pattern from a single observation.

Acceptance criteria

• A single, documented mechanism to fully disable RTK rewriting for one command invocation.
• Documented in the README under a heading an LLM is likely to retrieve (e.g. "Disabling RTK" or "Escape hatch for agents").
• Mentioned (as a one-line hint) in RTK's own condensed output footer, so an agent reading the summary sees how to escalate to raw output.
• Exit code of the underlying tool is preserved exactly; stdout/stderr stream through unchanged.

Related

This is adjacent to a few open issues that are essentially "RTK's rewriting silently dropped/altered output I needed" (#1772 tsc --pretty false-success, #1765 go test -cover coverage missing, #1773 empty hook output). Each of those is a real bug to fix on its own, but a generic escape hatch would also have unblocked the agent in each case as a fallback while the specific wrapper bug is being fixed.