Conversation
added 2 commits
September 18, 2026 17:39
…ile hop On win32, a resolved mcode.cmd currently prefers the sibling mcode.ps1 via powershell -NoProfile -File, then falls back to dirname(cmd)/node_modules. Two field failure modes on real installs (anonymized deployment report): - PowerShell 5.1 binds flag-shaped tokens (-input, --cwd, ...) as its own named parameters under -File, breaking the exec argv entirely - with the .ps1 renamed away, the fallback accepts whatever cli.js sits next to the PATH shim; when an old install (0.2.x) provides that shim while a newer official install exists, resolution silently picks the stale entry, which lacks current exec flags Resolution now prefers a directly spawnable node entry, picking the NEWEST cli.js across the candidate layouts (shim sibling, official lib/node_modules, official root node_modules) by package version; the powershell -File hop remains only as a documented last resort when no node entry exists anywhere. POSIX resolution is unchanged. checks/win-launcher.check.mjs covers the mixed-install matrix by faking the win32 layout + PATH/PATHEXT from POSIX (resolution is pure filesystem probing); real-Windows behavior is exercised by the repository's windows CI job.
…wsh first From a full field debugging report on a real Windows deployment (anonymized): - executablePath probed the empty PATHEXT extension first for bare names, resolving mcode to the extensionless POSIX shim shipped beside mcode.cmd — spawn then fails with ENOENT. Bare names now match PATHEXT variants only; commands that already carry an extension (pwsh.exe) still probe directly. - the candidate pool for the node entry now includes the staged-installer layout releases/<version>/node_modules/@minimax-ai/code/cli.js — the same entry .mcode-launcher.cmd targets. A stale flat node_modules (0.2.x) beside a current releases/<v> now loses the version comparison instead of winning by proximity. - the last-resort PowerShell hop prefers pwsh.exe (PS7): PS 5.1 binds flag-shaped argv as its own named parameters under -File and does not forward piped stdin through the nested invocation (field-verified pair)
Contributor
Author
|
Substantially expanded after receiving the reporter's full field debugging notes (Windows 11 / PowerShell 5.1 + pwsh 7.6.6 / Node 26 / mcode 0.4.12; identities sanitized). Their four findings, mapped to this PR:
New regressions reproduce the reporter's exact on-disk layout from POSIX (extensionless shim + mcode.cmd + ps1 + stale flat node_modules + releases/0.4.12): red 3/3 on the previous head, green after. Suite now 10/10 launcher tests, 92/92 plugin-wide, packaged smoke 1/1, byte-reproducible rebuild. The reporter also supplied maintainer-runnable repro commands for the PS 5.1/PS7 pair and the direct |
The field-layout test probed mcode.CMD (uppercase PATHEXT) against a lowercase mcode.cmd fixture — Windows filesystems are case-insensitive so the behavior is fine in production, but the Linux CI runner simulating win32 is case-sensitive and resolution returned null. PATHEXT in the test now matches the fixture files; assertion gains an explicit non-null guard.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What changes
Fixes Windows mcode launcher resolution in
mcode-location.mjs— two failure modes observed on a real Windows deployment (details anonymized; a user's debugging session was shared with us verbatim):-Filehop. A resolvedmcode.cmdwith a siblingmcode.ps1is invoked aspowershell -NoProfile -File mcode.ps1 exec --input - --cwd .... Under-File, PowerShell binds flag-shaped tokens (-input,--cwd,--timeout …) as its own named parameters, so the exec argv never reaches the CLI — parameter-binding errors on every invocation. (The user's attempted--%stop-parsing cannot help: it affects interactive command lines, not-Fileargument passing.).ps1renamed away (the user's workaround), resolution falls back todirname(mcode.cmd)/node_modules/@minimax-ai/code/cli.js— the npm-global layout, whichever version sits there. On a machine with an old install (0.2.x, missing current exec flags) providing the PATH shim while a newer official install exists, resolution silently picked the 0.2.x entry and every exec call died on an unknown flag. The user eventually junction-linked the newcli.jsinto the expected path — a workaround this PR makes unnecessary.The fix
.ps1hop: collect candidatecli.jslocations (shim siblingnode_modules, officiallib/node_modules, official rootnode_modules) and pick the newest by package version — mixed installs resolve to the freshest CLI regardless of which install owns the PATH shim.powershell -Filehop remains only as a documented last resort when no node entry exists in any layout.Test evidence
checks/win-launcher.check.mjs(7 tests): the mixed-install matrix is reproduced from POSIX by faking the win32 on-disk layout and passingplatform:'win32'+ controlledPATH/PATHEXT(resolution is pure filesystem probing): ps1-present-with-old-sibling + newer official → direct node entry of the newest; ps1 renamed + stale sibling → newest official, never the stale one; newest-wins regardless of origin; single npm layout; ps1 last resort preserved (with-NoProfile,-File,<launcher>argv pinned); no-entry error message preserved; POSIX unchanged.Need help on this PR? Tag
@codesmith-botwith what you need. Autofix is disabled.