fix(shell): validate command names and tighten install/uninstall detection

[max-sixty]

Two shell-integration correctness fixes plus an uninstall-scope redesign.

Command-name validation. The shell-integration command name comes from the user-typed --cmd flag, or argv[0] when --cmd is omitted. A malformed value — an empty string, a leading -, or characters like ; or whitespace — renders into a broken shell rc line that the user then has to find and fix. validate_shell_command_name() rejects empty, leading--, and non-[A-Za-z0-9._-] names at the CLI entry points, so a bad value produces a clear error up front instead of a silently broken config file. This is input hygiene on a value the user already controls — not a security boundary.

Noncanonical-line detection on install. Install recognized only its exact current canonical line, so a manually-added or older-form integration line (e.g. eval "$(wt config shell init zsh)") was not seen as already-present and a duplicate was appended on the next install. It now detects those forms and reports already-configured.

Uninstall scans every worktrunk-managed file, regardless of cmd. Previously uninstall located Fish/Nushell wrapper files by name ({cmd}.fish / {cmd}.nu), so removing integration installed under an alternate binary name needed a matching --cmd. That symmetry leaked an implementation detail — uninstall already has a content marker to recognize worktrunk wrappers regardless of binary name. It now scans the wrapper directories (~/.config/fish/functions, conf.d, completions; the nushell candidates' vendor/autoload) and admits every file whose content matches the cmd-agnostic marker # worktrunk shell integration for <shell> (always emitted by the wrapper templates), with a regex fallback for older installs. For Bash/Zsh/PowerShell (line-based), is_shell_integration_line_for_uninstall_any_cmd extracts binary-name candidates from each line and reuses the execution-context check. The --cmd flag is removed from wt config shell uninstall; install keeps it (installing under an alternate name is still a deliberate per-cmd act).

Covered by new integration tests: custom-cmd install + cmd-less uninstall round-trips for zsh/fish/nushell (verifying scan-all removes the custom-cmd integration), malformed-name rejection at the CLI edge (--cmd and argv[0]), and the older-line dedup case.

This was written by Claude Code on behalf of Maximilian Roos

[worktrunk-bot]

codecov/patch is failing: the invalid_command_name_error helper added at the top of src/shell/paths.rs is uncovered (3 lines / 50% patch coverage on that file).

It only fires when one of the three paths.rs accessors (config_paths, legacy_fish_conf_d_path, completion_path) is called with an invalid cmd — but every CLI entry point validates first, so the structural guard is only exercised via Shell::is_shell_configured() / scan_for_detection_details(), both of which feed it the already-validated binary_name(). Per CLAUDE.md the patch check gates merge. Two reasonable fixes:

• Add a unit test in the existing mod tests block at the bottom of paths.rs calling one of the three accessors with "wt; touch" and asserting ErrorKind::InvalidInput.
• Inline the one-call-site-each std::io::Error::new(...) into the three .map_err(...) calls and delete the helper.

Either works — the test path also documents the contract.

Also flagged a small inline below.

[worktrunk-bot]

Two small concerns on the new uninstall scan-all logic — neither blocks, both are worth a look.

The is_shell_integration_line_for_uninstall_any_cmd regex extracts only wt from eval "$(git wt config shell init bash)" and eval "$(command git wt config shell init bash)", but is_valid_command_position then rejects it because the wt is preceded by git . So lines installed in the git wt … (separate-words) form — explicitly supported as a git-wt invocation in is_shell_integration_line_impl and exercised in detection.rs's #[case::git_space_wt] / #[case::command_git_wt] tests — are no longer removed by uninstall. The hyphen form (git-wt …) which install actually emits still works, so this only bites users with hand-edited rc files. Lifting the candidate to git-wt when the regex match sits behind git recovers the old behavior.

Separately, fish_wrapper_names: HashSet<String> (collected at line 994 and iterated at line 1111) is order-sensitive only when more than one worktrunk-managed Fish wrapper exists in the same install — every current test has at most one, so this isn't biting yet, but the completion-removal display order would flake. BTreeSet is a one-token fix.

[worktrunk-bot]

Suggested change

	let mut fish_wrapper_names: HashSet<String> = HashSet::new();
	let mut fish_wrapper_names: BTreeSet<String> = BTreeSet::new();

HashSet iteration is non-deterministic, so when more than one worktrunk-managed Fish wrapper exists the order of completion_results and the Removed … lines printed for completions depends on the hash seed. BTreeSet (with the matching import swap) gives a stable order and the API is otherwise identical here.

[worktrunk-bot]

The regex captures only wt from eval "$(git wt config shell init bash)" (and the command git wt … variant) — and is_shell_integration_line_for_uninstall(line, "wt") then rejects it because is_valid_command_position returns false when the candidate is preceded by git . So the git wt … invocation form — explicitly supported in has_init_invocation and exercised by detection.rs's #[case::git_space_wt] / #[case::command_git_wt] tests for cmd = "git-wt" — is no longer matched by the cmd-agnostic uninstall scan. The hyphen form git-wt … (what install actually emits) still works, so this only bites hand-edited rc files, but it's a behavior regression vs. the previous per-cmd uninstall path.

One way to recover it: after is_shell_integration_line_for_uninstall(line, candidate) returns false, if candidate == "wt" and the line text around the match shows a git prefix, retry with "git-wt". A targeted unit test on this helper with the two git wt forms would pin the behavior.