Activated pwsh loses the -- in mise exec -- cmd

[gtbuchanan]

In an activated PowerShell session, mise exec -- pnpm --version fails:

error: unexpected argument '--version' found
  tip: a similar argument exists: '--verbose'
Usage: mise exec [FLAGS] [TOOL@VERSION]… [-- COMMAND]…

The same command through the binary returns 11.25.0.

Cause

mise activate pwsh defines mise as a function, and PowerShell's parameter binder claims the first bare -- on a line as its own end-of-parameters token. It removes the token before $args is populated, so the function forwards exec pnpm --version and clap reads --version as mise's own.

The binder does this to any function, with no mise involved:

PS> function f { $args -join '|' }
PS> f exec -- pnpm --version
exec|pnpm|--version

It takes exactly one, wherever it sits: f a b -- c -- d gives a|b|c|--|d. No spelling of the function signature avoids it, and $args, [Parameter(ValueFromRemainingArguments)] and PositionalBinding=$false lose it identically. bash, zsh and fish forward "$@" untouched, which is why a single -- is all the docs mention.

Scope

Every command that takes a trailing -- is affected, including mise exec, mise x and mise run.

The failure needs nothing unusual to reproduce. It survives -NoProfile, every MISE_* and __MISE_* variable being cleared, and the activation script being generated fresh in the session rather than cached. It appears on Windows PowerShell 5.1.26100.8875 as well as pwsh 7.6.5.

It also fails quietly until it doesn't: the separator only matters once the command being run has a flag colliding with one of mise's own, so mise exec -- pnpm install works and mise exec -- pnpm --version does not.

Spellings that do work

mise exec '--' pnpm --version succeeds, because quoting defeats the binder's token recognition. So does mise.exe exec -- pnpm --version, which skips the function.

mise exec -- -- pnpm --version succeeds too, and is worth naming because it is what people arrive at on their own: the first -- dies in the binder and the second reaches clap. It is not portable. Outside an activated shell there is no function, both separators reach clap, and it fails with cannot find binary path. A script carrying the doubled form runs only where a profile happened to have activated mise.

Environment

version: 2026.9.5 windows-x64 (2026-09-10)
shims_on_path: yes

build_info:
  Target: x86_64-pc-windows-msvc
  Features: rustls-native-roots, self_update
  Rust Version: rustc 1.98.1 (48a229cea 2026-09-01)
  Profile: release

shell:
  pwsh
  PowerShell 7.6.5

[jdx]

Thanks — this is an unusually good report, and every part of the mechanism checks out. Fix in #13202.

I reproduced it on pwsh 7.6.6 on Linux as well, so it isn't Windows-specific at all: it's a property of PowerShell's function parameter binder wherever it runs. Your minimal repro holds exactly, including the "exactly one, wherever it sits" behavior:

f exec -- pnpm --version   →  exec|pnpm|--version
f a b -- c -- d            →  a|b|c|--|d

Worth adding: an alias to the native executable forwards -- intact, and a function never does. That's the whole difference, and it's why mise.exe exec -- … works — as you found.

One correction to your Scope section: mise run is not affected. It takes double_dash = "automatic" with unknown_flags = "value", so flags after the task name reach the task whether or not a separator survives. I checked mise run t -- --jobs 4, --quiet, --raw and the bare mise <task> --flag shorthand — all behave identically with and without the --. The commands that actually break are the ones where -- is required: mise exec / mise x, mise tasks add, mise dotfiles capture, mise oci run, mise generate git-pre-commit and mise bootstrap.

The fix. The raw invocation text still holds the separator, so the wrapper now parses $MyInvocation.Line, finds its own invocation by $MyInvocation.OffsetInLine (so two mise calls on one line each get their own repair), and puts -- back at the index the binder took it from. A regex checks for a bare -- before anything is parsed, so ordinary calls pay nothing; your quoted mise exec '--' … spelling is recognized as untouched and isn't given a second separator; and if the parsed elements don't map one-to-one onto $args — a splatted @array — it leaves the arguments alone rather than guessing.

One consequence you'll care about, given you named it: mise exec -- -- pnpm --version stops working in an activated shell once this lands. It will fail the same way it already fails without activation. You were right that it's not portable, and this makes it consistently non-portable rather than silently shell-dependent — but anyone who scripted the doubled form should drop back to a single --. Until the fix ships, mise exec '--' … is the spelling that works in both.

Existing PowerShell sessions keep the old wrapper until mise activate pwsh runs again.

AI-assisted — Tool: Claude Code; model: anthropic/claude-opus-5; version: 2.1.270.