rtk-ai/rtk

rtk err cargo build --help prints 707 B of cargo's 3135 B help (the lines the error filter keeps), and rtk test cargo test --help prints the last 5 lines of 3421 B. rtk summary <cmd> --help summarises the page. Same on develop 311ebcb. #4348 hands --help/-h/--version to the tool on wrapper subcommands, and leaves these three alone on purpose: they run a command the caller names, whose -h may not be a help request (rtk err du -h, rtk summary df -h), so a guard on the inner argv has to know the inner tool's spelling, as runner::help_spelling does for wrappers.

Summary #4530 closed the #4126 regression (a denied command inside a shell wrapper the rewrite reaches now returns Defer) with the smallest change that is never worse than master. Three things were left on purpose. All rows below were verified on release binaries of master 0.51.0, develop 311ebcbf and #4530 with allow Bash(*) + deny Bash(git push:*) (rtk rewrite exit: 0 allow · 1 passthrough · 2 deny · 3 ask). 1. A rewritten prefixed script is auto-allowed on the outer rule Command (allow Bash(env:*)) master develop #4530 env bash -c 'git status' → env bash -c 'rtk git status' 1 0 0 env bash -c 'git -C . push' → env bash -c 'rtk git -C . push' 1 0 0 env bash -c 'git reset --hard' with ask git reset:* 1 0 0 The host's outcome is unchanged (its own env:* rule allows the raw line), but RTK answers "allow" for a script it rewrote and only partly understood: the inner match reads past the prefixes the rewrite peels, not past a program's own options, and ask rules inside

ci.yml runs semgrep scan --baseline-commit ${{ github.event.pull_request.base.sha }}. On #3613, base.sha was 29f9bb716 (where the branch was cut) while develop was at 311ebcbfd. The job scans the merge result, so everything develop gained in between counts as new. It failed with one blocking finding, filesystem-deletion at src/hooks/init/opencode.rs:257, in a develop test, on a PR that touches build.rs, ci.yml and one new test file. Reproduced locally on the merge tree: --baseline-commit 29f9bb716 gives 1 finding, --baseline-commit 311ebcbfd gives 0. After develop was merged into the branch, base.sha became 311ebcbfd and the job passed (run 38322254442). Effect: any PR behind develop fails this job on findings it did not introduce, until its author merges develop. Separate from #3761, which covers an empty baseline on other triggers. Possible baselines, not tried on a runner: the first parent of the merge ref (the base tip when the merge ref was built), or origin/<base_ref> after a fet

Summary The official Hermes plugin (hooks/hermes/__init__.py, installed via rtk init --agent hermes) calls subprocess.run(["rtk", "rewrite", command], capture_output=True, text=True) without an explicit encoding=. On Windows, text=True decodes the child's output with the ANSI code page (cp936/GBK on zh-CN systems) — but rtk rewrite emits UTF-8. Any command containing characters that don't round-trip through GBK (non-ASCII paths, curly quotes, emoji — i.e. most real-world commands on CJK Windows) makes the reader thread throw UnicodeDecodeError, so result.stdout is left as None, and the plugin then crashes on result.stdout.strip(). The exception is swallowed by the plugin's wide except, so the command fails open and runs unrewritten. No data is corrupted, but the plugin silently loses 100% of its rewriting benefit for those commands, plus emits one stderr noise line per call. The user sees nothing except "rtk gain never goes up". Environment rtk 0.50.0 (winget rtk-ai.rtk); same def

Three small refinements to disown_pair / opens_disown_pair (src/discover/lexer.rs), added in #4126 to stop RTK re-spelling the pairs an ampersand opens. The rule itself is correct and verified against real zsh 5.9.2 and fish 4.9.1; these are leftovers that cost nothing today but will mislead the next reader. 1. The TokenKind::Arg arm is unreachable let pairs = match &token.kind { TokenKind::Pipe(_) => true, TokenKind::Shellism => token.value == "!", TokenKind::Arg => token.value.starts_with('!'), // <- never fires _ => false, }; An unquoted ! is unconditionally flushed into its own Shellism token by the '*' | '?' | '' | '(' | ')' | '{' | '}' | '!'arm oftokenize_inner, and every other producer of an Argprepends something: the quote branch keeps the opening delimiter invalue (&'!x'→Arg("'!x'")), the escape branch keeps the backslash (&!x→Arg("\!x")), and the $branch yields$name. So no Argvalue can begin with!`. Evidence: removing the arm changes the verdict on 0 of