fix: a Windows-path-aware commandArgv0

[nedtwigg]

tokenizeCommand treated every \ outside single quotes as a POSIX escape, so
a command line reported by PowerShell or cmd lost its path separators before
commandArgv0's basename split could see them. Everything keyed on the program
name silently missed when the user (or a launcher, or a shim) invoked by
absolute path:

command line	before	after
C:\Users\me\.claude\local\claude	C:Usersme.claudelocalclaude	claude
C:\tools\dor.cmd tool storybook	C:toolsdor.cmd	dor
& "C:\Program Files\nodejs\npm.cmd" run dev	null	npm

Rules are only ever created from the running command's own argv0 (the bell
dialog toggle — nobody types a name), so a mangled key was self-consistent and
did match the same line again. What missed is the same program reached two ways:
a rule made while running claude from PATH never rang for a Session launched
as C:\Users\me\.claude\local\claude, and the & form had no argv0 at all,
so there was no name to key a rule on. Pane headers and the TODO dialog rendered
the mangled text throughout. The dor tool take-over gate in #514 has the same miss and picks
this up for free — one tokenizer, so the gate and the header can never disagree
about a command line.

The fix

A \ escapes only what a shell actually escapes; before anything else it is a
literal separator. The escapable set is shellEscapePosix's own
POSIX_ESCAPABLE, shared rather than re-derived, so POSIX escapes keep their
meaning (foo\ bar is one token, \*.ts passes a literal glob) and a path
Dormouse itself escaped for a drag-and-drop paste reads back as itself — the
two sets had silently disagreed about ~.

Three consequences worth calling out:

• PowerShell's & call operator. & "C:\...\npm.cmd" run dev — the only
  way that shell runs a quoted program path — returned null, because a bare
  & at index 0 read as a boundary leaving no command. A leading & is never
  a POSIX background suffix, so it is dropped.
• .cmd/.exe is how the same program spells itself on Windows, so the
  suffix is not part of its name: npm.cmd, C:\tools\claude.exe and
  build.ps1 reduce to npm, claude and build for the WATCHING key, the
  header, and the bell tooltip alike (commandProgramName). Keeping it would
  leave npm and npm.cmd as two rules for one program, which is the miss
  this PR exists to close. Accepted: foo.bat and foo.exe in one directory
  cannot be watched separately. isGenericProcessTitle keeps the plain
  basename — there the suffix is the evidence it tests for.
• Stale WATCHING keys are dropped, and that is user-visible. Two shapes can
  never match again and cannot be migrated: a key the old mangling wrote
  (C:\tools\claude.exe -> C:toolsclaude.exe, tools\dor.cmd ->
  toolsdor.cmd), and any key ending in a launcher suffix, including one that
  stored cleanly (npm.cmd), now that commandProgramName strips it.
  isKeyableName drops both — a separator, a leading X: drive prefix, or a
  launcher suffix, none of which commandArgv0 can return. The drive prefix is
  narrow on purpose: a bare : is legal in a POSIX basename, and rejecting
  every colon-bearing name would silently no-op the bell toggle for one. A Windows user whose rule was working
  loses it on upgrade and re-enables it once from the bell dialog, now keyed on
  a real program name. Residual: a mangled relative path with no suffix
  (bin\claude -> binclaude) reads exactly like a program named that, so it
  survives as a dead row to delete by hand.

Not delivered: the unquoted Windows path with spaces

HANDOFF.md wanted C:\Program Files\nodejs\npm.cmd run dev to reduce to
npm.cmd. I built that (re-join the leading tokens, commit on an executable
suffix) and then removed it, because review showed it returning the wrong
argv0 rather than a miss:

"C:\Program Files\Git\bin\bash" scripts\bootstrap.cmd  ->  bootstrap.cmd
C:\tools\node .\scripts\build.cmd                      ->  build.cmd

The first is the normal PowerShell idiom, and it broke because the tokenizer
discards quoting, so the join cannot tell a complete program path from one
continued by an argument. Teaching it to track quotes would not save the second:
A\B C\D.cmd is genuinely A\B plus an argument as often as it is one path,
and nothing short of the filesystem can say which. It also missed most of what
it was meant to catch (Program Files (x86)\Microsoft VS Code, extension-less
Program Files\nodejs\node, forward-slash drive paths).

Worth saying plainly: the brief's wanted value for that row looks wrong. The
unquoted form is a parse error in PowerShell — which is the only Windows shell
with real OSC 633 integration — so it could only ever arrive from cmd.exe, which
has no per-command hook and reaches us through the keystroke fallback. Whether
cmd's own parser accepts it I have not verified; CreateProcess documents
prefix-probing when lpApplicationName is NULL, but that is the API, not the
shell. Either way the shape stays split: a miss, never a wrong program name —
the same trade #514 accepted. The quoted form PowerShell requires works from the
escape fix alone.

Verification

pnpm lint:specs and the full lib suite (1996 tests) pass; tsc --noEmit is
clean. The new command tokenizer dialects table pins both dialects, the POSIX
escapes as regression pins, and — character by character — that
shellEscapePosix output round-trips and that no path character is in the
escapable set. jsdom covers the parsing; the payoff is on Windows, where a real
check is a PowerShell pane running an absolute-path command and confirming the
header shows the program name and a WATCHING rule on that name rings.

🤖 Generated with Claude Code

https://claude.ai/code/session_01KzMCg7c37NRvdLEhpwmPpz

[cloudflare-workers-and-pages]

Deploying mouseterm with    Cloudflare Pages

Latest commit:	af7a7b2
Status:	✅  Deploy successful!
Preview URL:	https://44018c8e.mouseterm.pages.dev
Branch Preview URL:	https://windows-argv0.mouseterm.pages.dev

View logs

[dormouse-bot]

The tokenizer change reads correctly and I reproduced every row of the dialect table by executing the extracted tokenizeCommand / takePrimaryCommandTokens / commandBasename under node — all twelve pinned cases hold, including the two undecidable-path misses. 714da04d is the right fix for the Build & Test red on ea36545 (Cannot find package 'dor/commands/shell-quote' … ❯ terminal-state.ts:1:1, five vscode-ext/test/message-router.test.ts cases); POSIX_ESCAPABLE now has exactly one definition and three importers, all repointed.

One thing beyond the two inline notes:

The suffix strip lands on the display name but not on the key, and this PR is what splits them. commandTitleTokens strips .exe/.cmd, so C:\tools\claude.exe --print summarizes as claude --print, while commandArgv0 returns claude.exe. Before this PR the two agreed (both mangled to C:toolsclaude.exe); now the pane header reads claude, WatchedCommandList renders the rule row as claude.exe, and the bell tooltip says [a] Alert on all "claude.exe" — three names for one program on one screen. A rule created from a .exe/.cmd invocation is also a second row that never rings for the same program typed bare, which is the miss the PR opens on, one dialect over. The argument in the body — ".cmd/.exe is how the same program spells itself on Windows" — applies unchanged to the key.

Keeping them distinct is defensible (foo.bat and foo.exe really can be two files in one directory, and the rule set is the one place conflating them is irreversible from the UI). But it is currently pinned by a test and stated nowhere, so if it is the intended trade it is worth a line in alert.md or on commandArgv0 — that doc comment already says "This is the key WATCHING rules are stored under", which is exactly where a reader would look for it.

Smaller notes, not worth blocking on

• setCommandWatched doesn't run its argument through isKeyableName, so a key that normalize will later drop can still be stored: commandArgv0('C:foo.exe') (a legal drive-relative invocation) returns C:foo.exe, which matches in-session and then vanishes on the next reload with no feedback. Narrow enough to leave.
• In VS Code the extension host keeps its own stale key and rebroadcasts it; the renderer filters it every time, so the state is stable but never actually cleaned up on the authoritative side.
• The character list in the round-trip it.each is a hand-maintained copy of POSIX_ESCAPABLE's contents. It pins that each listed character is in the set, but a character added to the regex later wouldn't fail anything — the companion path-character test only covers a fixed allowlist.
• posix-escape.ts says terminal-state.ts is bundled into the VS Code extension host and the Tauri sidecar. What the red run actually showed is the vscode-ext vitest process resolving the specifier without the tsconfig dor/* mapping; the sidecar half isn't demonstrated by anything I can see. The rule the comment states is right either way.

[nedtwigg]

Thanks — all five landed in 4a47693, plus the main point.

One name per program. You're right that this PR is what split them, and the argument for stripping applies to the display, not to the key. So: strip for matching the per-program cases (which is what makes them fire on Windows at all), render the basename as invoked. C:\tools\claude.exe --print is now claude.exe in the header, the rule row, and the tooltip; npm.cmd run dev still gets the npm case, and reads npm.cmd run dev. Verified the header's first word equals commandArgv0 across the launcher shapes.

The key keeps the suffix for the reason you gave — foo.bat and foo.exe can be two files in one directory, and the rule set is the one place conflating them can't be undone from the UI. That's now stated on commandArgv0's doc comment, where you pointed.

The escape-set cost. I had it backwards and you're right. Against this branch:

C:\tools\$claude.exe --print  ->  tools$claude.exe
C:\bin\(x86)tool.exe          ->  bin(x86)tool.exe
C:\$Recycle.Bin\foo.exe       ->  foo.exe

The last one is display-only only because the damage sits upstream of the final separator, exactly as you said. Comment corrected.

Smaller notes. setCommandWatched now applies the same isKeyableName gate normalize does, so C:foo.exe can't be stored and then vanish. The round-trip it.each now pins the set in both directions, so a character added to the regex fails there too. And you're right that posix-escape.ts overclaimed the sidecar — it mirrors constants by hand and imports nothing from lib; narrowed to the extension host.

I left the VS Code host-side stale key alone: the host is seeded from the renderer's already-normalized list on each host start, so the authoritative side gets the filtered set rather than keeping a stale one.

Root suite green — lib 1996, vscode-ext 113, standalone 62, website 65, and all five lints.

[dormouse-bot]

Re-ran the extracted tokenizeCommand / takePrimaryCommandTokens / commandProgramName under node against every row of the dialect table plus the new suffix cases — all hold, including & C:\tools\dor.cmd → dor and the two undecidable-path misses. Folding commandTitleTokens' match-vs-render split onto one commandProgramName is the right shape: the header, the rule row and the tooltip now provably read the same name, and the it.each table pins commandArgv0 and summarizeCommandLine on the same row, so they can't drift apart silently. pnpm lint:specs is green on the merged tree.

Two things on the reversal.

The stale-key sweep only reaches drive-absolute invocations — inline on isKeyableName. Relative-path invocations (tools\dor.cmd, .\build.ps1) mangled to keys with no : and no separator, so they pass the gate and are now permanently dead rows; and npm.cmd typed without a path never went through the mangling at all, which is the case 0698588's "no shipped build ever stored a suffixed key" doesn't cover.

alert.md still specifies the old key. The WATCHING rules list — "The key is commandArgv0(rawCommandLine) … then reduce argv[0] to its basename" — gives only POSIX examples, so a reader computing the key for npm.cmd from that line gets npm.cmd. terminal-state.md states the new rule, but alert.md is where the key itself is specified, and it now contradicts the code. It's outside the diff so I haven't touched it; happy to push the one-line amendment if you want it.

Minor: commandTitleTokens names its local basename while it now holds commandProgramName(command), three lines below a commandBasename that means the other thing. program would keep the distinction this PR is about.

[dormouse-bot]

Both fixes from the last round land. alert.md's key line now points at terminal-state.md rather than restating the rule, and the local is program. The stale-key gate I confirmed on 72f01c1e is unchanged here, and pnpm lint:specs is green on the merged tree — alert.md at 7598 of its 7600-word budget, which is presumably why the Windows example went to the pointer rather than the line.

One new thing, from the gate the increment added — inline on isKeyableName.

[dormouse-bot]

commandProgramName strips one suffix; this gate rejects any name ending in one, so the two are not inverses and the sentence above ("it never ends in a launcher suffix") is false for a doubled extension:

commandProgramName('a.exe.exe')  ->  'a.exe'
isKeyableName('a.exe')           ->  false

(run against the two functions as written on this branch). That is a live argv0, not a stale key, and the failure mode is the one the write-path gate was added to prevent, one step worse: TodoAlertDialog renders Alert on all "a.exe", setCommandWatched early-returns, and on={watched.includes(argv0)} never flips — the switch is a permanent silent no-op rather than a rule that vanishes on reload.

It isn't fixable, which is why I'd state it rather than patch it: a stored npm.cmd is genuinely ambiguous between the stale key this gate exists to drop and the argv0 of npm.cmd.cmd, so any predicate that drops the first refuses the second. Same shape as the binclaude residual already documented here, so it reads naturally as the second one:

Suggested change

	*
	* Residual: a mangled *relative* path with no suffix (`bin\claude` ->
	* `binclaude`) is indistinguishable from a program actually named that, and
	* survives. The user deletes it from the rule list.
	*
	* Two residuals, both undecidable rather than fixable. A mangled *relative*
	* path with no suffix (`bin\claude` -> `binclaude`) reads exactly like a
	* program named that, so it survives for the user to delete. And a program
	* whose name genuinely ends in a suffix (`a.exe.exe`, argv0 `a.exe` — the
	* strip takes one) is refused rather than stored, because its key cannot be
	* told apart from the stale `npm.cmd` this gate drops.

Rare either way — but the doc comment currently claims the case can't arise, and it's the claim a later reader would rely on.

[dormouse-bot]

Re-ran the extracted tokenizer / commandProgramName / isKeyableName under node against the increment. The drive-filter narrowing is right, and it recovers live keys the broad : test was deleting — ./foo:bar -> foo:bar and C:\Users\me\a.b:c -> a.b:c are keyable now, while every row of the stale-key table still drops on both the read and write paths (C:toolsclaude.exe, toolsdor.cmd, .build.ps1, ..binnode.exe, npm.cmd). The new foo\-bar -> -bar pin holds, and afterEach's clearRules still empties the store after the added foo:bar rows, since both are keyable and therefore removable. pnpm lint:specs green on the merged tree.

One inline finding, on the tokenizer comment the increment rewrote.

Two more for the still-open isKeyableName thread, so its edit lands complete instead of needing a third round:

• WINDOWS_EXECUTABLE_SUFFIX's own doc comment carries the same claim — "which drops a stored key ending in one: commandArgv0 cannot produce one" — so the suggestion on isKeyableName leaves it false in terminal-state.ts. (The PR body's stale-keys bullet says it a third time: "none of which commandArgv0 can return".)
• The drive clause has the same shape as the suffix clause. commandArgv0('C:foo.exe --print') returns C:foo, which the gate refuses, so the bell dialog reads Alert on all "C:foo" and the switch is a permanent no-op rather than a rule that vanishes on reload. watched-commands.test.ts already names that shape ("a drive-relative invocation is the one shape commandArgv0 can still return with a : in it"), so the behavior is the intended trade — it is "a stored key is one commandArgv0 can still produce" that overclaims, in a second dimension.

[dormouse-bot]

Verified against this branch, the key is tools$claude — commandProgramName strips the .exe after the mangled basename split, so the example predates the suffix strip landing in this PR:

C:\tools\$claude.exe --print  ->  tools$claude

The corrected value also flips the consequence. tools$claude.exe would be dropped by isKeyableName (launcher suffix), so the comment as written reads like the cost is self-cleaning; tools$claude passes all three clauses, so it persists as a second rule row for the program a bare claude keys as claude.

Suggested change

	* `-bar`), while an eaten Windows separator leaves `C:\tools\$claude.exe`
	* keyed as `tools$claude.exe`.
	* `-bar`), while an eaten Windows separator leaves `C:\tools\$claude.exe`
	* keyed as `tools$claude` — a name `isKeyableName` accepts, so it persists as
	* a second rule row for the program a bare invocation keys as `claude`.