[max-sixty]

shell::extract_filename_from_path compared a file name's last four bytes against .exe by slicing at len() - 4, with no char-boundary check. Any name whose last four bytes start mid-character panicked.

Before and after, at the CLI

$ SHELL=/bin/日本語 wt config show
thread 'main' panicked at src/shell/utils.rs:21:38:
start byte index 5 is not a char boundary; it is inside '本' (bytes 3..6 of string)
exit=101

$ SHELL=/bin/日本語 wt config show   # with this change
...
▲ Shell integration not active
  $SHELL: /bin/日本語
exit=0

$SHELL is the mild case. On macOS ps_snapshot feeds every process name on the machine through this function, so a single CJK-named process crashes any command that detects the shell.

The fix reuses path::strip_suffix_ignoring_case — the str::get-based helper #3719 added for naming wt from argv[0] — now pub(crate) and called with .exe. That leaves one case-insensitive suffix-stripper where there were two, one safe and one not.

One deliberate behavior change beyond the panic: a name that is nothing but the suffix (.exe) now yields None rather than Some(".exe"). All three callers already handle None by falling through to their next detection source, and Some("") — what a naive swap would produce — would have reported an empty shell name.

I checked for siblings of the same defect class; this was the only one. Every other computed slice index in src/ derives from find(), which returns char boundaries.

This was written by Claude Code on behalf of max-sixty