Repository navigation
Panic (SIGABRT, exit 134) on non-UTF-8 bytes in argv — std::env::args() unwrap #3025
Description
First off — thank you for maintaining rtk. The 0.43 releases (the never-worse output guard, the grep engine fix) have made it noticeably more trustworthy in day-to-day agent use, and that work is appreciated.
Summary
rtk aborts with a Rust panic (SIGABRT, exit 134) when any command-line argument contains bytes that aren't valid UTF-8. The panic fires in std::env::args()'s per-argument unwrap, before the wrapped command runs.
Reproduction (rtk 0.43.0, macOS arm64, zsh)
The pattern below is the leading bytes of a double-encoded UTF-8 sequence — the kind of byte fragment you end up grepping for when hunting mojibake in a repo, which is how we hit this in real work:
$ printf '\xc3\xa2\xe2\x80\xa0\n' | rtk grep -c $'\xc3\xa2\xe2\x80'
thread 'main' panicked at /rustc/.../library/std/src/env.rs:875:51:
called `Result::unwrap()` on an `Err` value: "â\xE2\x80"
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
$ echo $?
134Expected
Either pass the raw bytes through to the underlying engine (system grep handles them fine under LC_ALL=C), or exit with a normal, clear error message — anything but an abort.
Notes
- Reproduced on two different days on 0.43.0 (macOS arm64).
- This looks distinct from the existing char-boundary panic family (panic: rtk gain --history crashes on non-ASCII (Cyrillic) command strings — UTF-8 char boundary #2954, rtk gain --history panics on non-ASCII (CJK) filenames in command history #2318, rtk find panics on non-ASCII path (byte index not a char boundary, find_cmd.rs:326) when an unknown flag like -print is present #2851), which involve valid multibyte text hitting byte-index arithmetic. Here the argv itself is invalid UTF-8 and the panic comes from
std::env::args()— so switching the entry point toargs_os()with lossy or graceful handling would likely cover this whole class at one boundary.
Thanks again for all the work that goes into this tool.
Activity
pszymkowiak commentedon Jul 16, 2026
🔍 Automated Triage
bughighSummary
Non-UTF-8 bytes in argv cause std::env::args() unwrap panic (SIGABRT/exit 134) before the wrapped command runs; switch to args_os() with lossy/graceful handling.
📁 Relevant files
src/main.rsTriaged automatically by wshm · This is an automated analysis, not a human review.
mgwedd commentedon Jul 26, 2026
Opened #3224 for this. Root cause is
run_fallbackinsrc/main.rscallingstd::env::args(), which aborts on any non-UTF-8 argument. The usesargs_os()/OsStringso the original bytes are reproduced unchanged. It derives lossy strings only for display.restore_double_dashinsrc/core/args_utils.rshad the same call problem and I made the same fix there.KuSh commentedon Oct 23, 2026
One more reach for this, from #4727 (
rtk ruffnow callsrestore_double_dash, which readsstd::env::args()): with rtk invoked by an absolute path whose directory name is not UTF-8,rtk ruff check subpanics (exit 101) on that head, where develop 5ab6291 ran it.rtk git statusfrom the same binary already panics on develop for the same reason. Invoked by name throughPATH(argv[0] =rtk, the hook's form), neither panics. #3224 switchesrestore_double_dashtoargs_os(), which covers this call too.guryanov-a commentedon Nov 5, 2026
Still reproduces on rtk 1.1.0 (macOS arm64, zsh), the current release:
rtk grep -c $'\xf0\x9d' <file>panics withcalled Result::unwrap() on an Err value: "\xF0\x9D"and exits 101. We hit it through the Claude Code hook, which routes ordinary shell commands through rtk, so the agent's command fails outright. #3224 would fix it.Written by Claude Opus 5.5 in Claude Code