Next Release

[rtk-release-bot]

Feats

• feat(hooks): add Trae IDE integration #3008 — Closes #1676 (to verify), #3234 (to verify)
• feat(config): add suppress_hook_warning option #776 — Closes #682 (to verify)
• feat(ast-grep): add ast-grep filter (rtk ast-grep) #3857 — Closes #3856 (to verify)
• feat(hooks): add direct Codex command rewriting #3552 — Closes #1003 (to verify), #1812 (to verify)
• feat(core): add arg_tokenizer and migrate git/grep/dotnet/golangci arg parsing onto it #3681 — Closes #3710 (to verify)
• feat(git): filter large git show blob dumps with recovery and Latin-1 decoding #3265
• feat(ci): add winget manifest automation #1318 — Closes #383 (to verify)

Fix

• fix(tracking): keep the user's arguments out of the telemetry command label #4123
• fix(docs): add git repo badges #4075
• fix(hooks): keep rtk init --codex inside the project and off the user's files #4119
• fix(git): stop show reporting on HEAD and log capping in silence #4117
• fix(git): make the blob recovery hint work under RTK's own hook #4118
• fix(ast-grep): account for every match line and stop capturing other subcommands #4121
• fix(core): cap the stderr a stdout-only filter forwards on a clean run #4120
• fix(read): stop the head window reading past the lines it was asked for #4122
• fix(core): quote child arguments so MSYS children receive them intact #3728 — Closes #3727 (to verify)
• fix(tests): make dotnet_trx mtime-dependent tests deterministic #4048 — Closes #4037 (to verify)
• fix(pnpm): rewrite pnpm commands with global flags before the subcommand #3275
• fix: suppress hook warning during rtk init and verify #1422 — Closes #1011 (to verify)
• fix(read): make head/tail rewrites faithful to the native commands #3941
• fix(tracking): weighted savings rate in low_savings_commands and avg_savings_per_command #1298
• fix(gain): use weighted savings rate in per-command stats #891
• fix(gh): don't early exit on failure for "pr checks" #1122
• fix(gh): deduplicate watched PR checks #3542 — Closes #3541 (to verify)
• fix(npm): recognize extended subcommands #3087 — Closes #2663 (to verify)
• fix(core): stdout-only filters silently swallow a tool's stderr #3772
• fix(prisma): stop migrate status panicking on a trailing migration id #3836

Other

• chore: migrate to Rust edition 2024 and adopt let-chains #3782
• test(diff): pin the shape detectors, the structural index lines and the GNU roots #3923
• refactor(hooks): consolidate the hook decision behind one shared decide #3955 — Closes #3936 (to verify)

[KuSh]

Codex hook asserts permissionDecision: "allow" unconditionally — 7f2788a, PR #3552 The deny branch is unreachable. Repro: pipe a PreToolUse Bash payload with permission_mode: "default" into rtk hook codex.

hooks/codex/README.md documents that Codex requires it for updatedInput and that its native checks still run. The "deny branch is unreachable" part is true but is dead code, not a behaviour bug. And "dead code" is exercised by test_codex_shared_decision_preserves_host_approval_and_deny test and permissions::load_rules_for already states that ATM it is unreachable (even if it reads as reachable).

Telemetry query now admits negative-savings rows — cb5e599, PR #1298 The field retains the user's first argument. Reachability unproven: I could not produce a negative-savings row across a sweep of ordinary commands. Repro: synthetic negative row against the new HAVING; master excludes it.

reachability is real: rtk git worktree, -7.7 % over 2103 calls in my real DB. But there's a real issue: take(3) on rtk_cmd can ship a user argument to telemetry; the same leak 15f666d fixed for top_passthrough. But fixing it needs a grouping decision (first two words loses git log vs git status)

[KuSh]

This git commit will certainly have to change for the master to benefit from it

[aeppling]

Re-verified after #4117–#4122

7 of the 10 items are solved. Confirmed by re-fuzzing, not just re-running the original repros: 1464 git show flag permutations (0 divergences), 588 git log permutations, 640 head/tail byte-exactness cases, 558 hostile-arg cases (0 panics, 0 hangs). Gates green: 3920 tests, clippy and fmt clean.

Solved: git show wrong commit (#4117), RTK.md deletion (#4119), git log silent truncation on the -p path (#4117), blob recovery hint (#4118), forwarded stderr on clean runs (#4120), ast-grep accounting and over-capture (#4121), .codex symlink escape (#4119).

Partially fixed

head unbounded read (#4122). Memory is fixed — constant 15.7 MB on both a 10 MB and a 48 MB file. /dev/urandom returns. Still hangs on /dev/zero, where native BSD head fails fast with exit 1.
Repro: rtk read /dev/zero --head-lines 5 under an alarm, versus /usr/bin/head -5 /dev/zero.

Still open

Codex hook asserts permissionDecision: "allow" unconditionally — hook_cmd.rs:912. Narrower than I first described: the allow appears only for commands RTK rewrites. rm -rf /, sudo …, curl … | sh, npm publish, kubectl delete all produce no output, so RTK defers and Codex handles them natively. The residue is wrapped mutating commands, and the Claude hook omits the field entirely on the same input.
Repro: pipe a PreToolUse Bash payload for git push --force origin main with permission_mode: "default" into rtk hook codex, then the same into rtk hook claude.

Telemetry admits negative-savings rows with the first argument attached — tracking.rs:1340 and :1346 unchanged. Weakest of my findings: I still cannot produce a negative-savings row through ordinary use.

Fuzzing found no new regressions from the six fix PRs. It did surface a few pre-existing issues outside this release's scope, which I'll raise separately rather than hold the release on.

[KuSh]

Thanks for re-fuzzing rather than re-running the original repros — the permutation counts are what make "solved" mean something here.

All three remaining items have an answer; one of them I think changes the framing, so it is first and with the measurements attached.

head on /dev/zero

I do not think this is a divergence from native head, and on Linux it is measurably not one:

rtk read /dev/zero --head-lines 5   -> exit 124 (timed out)
/usr/bin/head -5 /dev/zero          -> exit 124 (timed out)

GNU head hangs exactly as rtk does. So the behaviour you are comparing against is BSD-specific, and it is worth being precise about what BSD does, because it is not a fast refusal.

From Apple's text_cmds/head/head.c, the read loop is:

while (cnt != 0 && (cp = fgetln(fp, &readlen)) != NULL) { ... }

fgetln grows an internal buffer until the line ends. /dev/zero never supplies a newline, so it grows until allocation fails and returns NULL. The loop exits, ferror(fp) is set, and main does warnx("Error reading %s", *argv); eval = 1; then exit(eval). The exit 1 is an out-of-memory failure reported as a read error, not a guard that recognised an endless stream.

Which produces an inversion worth naming: #4122 is the reason rtk no longer reproduces that. Before it, rtk grew unbounded on such a stream and would have died the same way BSD does. Capping memory at a constant is precisely what lets it keep going instead. The residue you are seeing is a consequence of the fix working, not of it being incomplete.

That leaves a real design question, which I am happy to take, but I would rather take it deliberately than as a regression fix: should rtk read --head-lines refuse a single line that exceeds some cap? Doing so would match BSD's outcome on purpose rather than by exhaustion — and it would make rtk diverge from head on Linux, where hanging is the platform behaviour. If you have a view on which parity matters more, I would take it.

Could you say which platform you measured on? If it was macOS, the two of us are describing the same behaviour from different sides.

Codex hook permissionDecision: "allow"

Your narrowing matches what I measure. On current develop:

$ echo '{"hook_event_name":"PreToolUse","tool_name":"Bash",
         "tool_input":{"command":"git push --force origin main"},
         "permission_mode":"default"}' | rtk hook codex
{"hookSpecificOutput":{...,"updatedInput":{"command":"rtk git push --force origin main"},"permissionDecision":"allow"}}

$ ... | rtk hook claude
{"hookSpecificOutput":{...,"updatedInput":{"command":"rtk git push --force origin main"}}}

$ ... "rm -rf /tmp/xyz" | rtk hook codex
(no output)

The asymmetry is protocol-driven rather than an oversight: Codex cannot accept updatedInput with ask or with the field omitted, and Claude has no such requirement. That is in hooks/codex/README.md line 14 and in the comment at the site you cite.

The residue you describe is already stated there in those words — "This can add prompts for known-safe commands and obscure classifier signals for wrapped mutating commands such as git push" — together with why: Codex applies the replacement before its own approval and sandbox checks, and its safe/dangerous classifiers do not unwrap rtk, so they classify the rewritten argv.

So I would treat this as a documented boundary of the Codex integration rather than an unfixed defect, and the thing that would actually close it is Codex unwrapping rtk in its classifier, which is not ours. The deny branch remaining unreachable is dead code rather than a behaviour bug, exercised by test_codex_shared_decision_preserves_host_approval_and_deny, and permissions::load_rules_for says as much.

Telemetry

You are seeing tracking.rs:1346 unchanged because the fix is in #4123, which is open and mergeable rather than merged. It replaces exactly that line:

-  let short = cmd.split_whitespace().take(3).collect::<Vec<_>>().join(" ");
+  let short = command_label(&cmd);

command_label resolves the grouping problem that was blocking this: it keeps the prefix and the tool, and keeps a third word only when the tool is a known subcommand router and the word looks like a subcommand. So git log and git status stay distinct while the user's arguments stop reaching the label.

The HAVING at :1340 is deliberately unchanged. Negative-savings rows are reachable — rtk git worktree sits at -7.7% over 2103 calls in a real database — and surfacing them is the point of that query. The defect was only ever the argument leak, which is the same one 15f666dd fixed for top_passthrough.

Rest of the set

Six follow-up PRs from the same review are open — #4148, #4149, #4150, #4152, #4153, #4154 — covering non-blocking findings in the areas the merged fixes touched. Worth knowing they exist before the fuzzing you mentioned lands on the same code.

Please do raise the pre-existing issues you found whenever suits you — separately is fine, as you suggested, and equally fine here if any of them turn out to touch this set. I will triage them against develop as they come in.