docs(troubleshooting): offer shims for the Windows Path limit, and fix the test for it - #11642
Conversation
📝 WalkthroughWalkthroughThe troubleshooting guide documents the Windows ChangesWindows PATH troubleshooting
Estimated code review effort: 1 (Trivial) | ~5 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Greptile SummaryThe troubleshooting documentation now accurately describes how an oversized Windows
Confidence Score: 5/5The PR appears safe to merge. No blocking failure remains. Important Files Changed
Reviews (3): Last reviewed commit: "docs(troubleshooting): correct the Windo..." | Re-trigger Greptile |
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@docs/troubleshooting.md`:
- Around line 150-160: Update the troubleshooting example around the cmd.exe Git
probe to first verify that Git is installed and available through the normal
Path using git --version outside the cmd.exe invocation. If Git is unavailable,
instruct readers to substitute another known executable located outside
C:\Windows\System32, so the test distinguishes Path handling from a missing
installation.
- Line 137: Update the troubleshooting statement near the Path-length limit to
clarify that cmd.exe ignores an overlong inherited Path, so commands found only
through Path fail while directly resolvable System32 commands may still work;
retain the Microsoft documentation link and avoid claiming that every command
becomes unrecognized.
- Line 162: Revise the v2026.5.18 description in the troubleshooting
documentation to state that mise stopped retaining stale inherited install paths
during reactivation, while continuing to add install directories for the current
toolset. Preserve the separate v2026.7.18 exact-duplicate collapse statement and
the surrounding explanation about the 8191 limit.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Central YAML (base), Organization UI (inherited)
Review profile: CHILL
Plan: Pro Plus
Run ID: 14612c7a-e9b8-4cf6-9301-b8d3017d169b
📒 Files selected for processing (1)
docs/troubleshooting.md
6641448 to
c78c78b
Compare
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@docs/troubleshooting.md`:
- Line 160: Update the troubleshooting test guidance around the `where.exe`/`git
--version` probe to require an executable located outside both
`C:\Windows\System32` and the current working directory. Retain the precondition
that the executable runs normally and is available through `Path`, so a local
working-directory match cannot produce a false positive.
- Line 141: Update the shims guidance in the troubleshooting entry to scope its
benefit to preventing activation-time Path growth. Clarify that each shim still
invokes mise to construct the tool environment, so tools that launch child
processes such as cmd.exe may still inherit an overlong Path.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Central YAML (base), Organization UI (inherited)
Review profile: CHILL
Plan: Pro Plus
Run ID: 2fc64853-7309-4db0-8ead-7a455fd0e339
📒 Files selected for processing (1)
docs/troubleshooting.md
…est for it Measured on Windows 11 26200 (cmd 10.0.26100.8875): - The documented probe never fails. `where.exe` is in System32, which cmd.exe resolves without consulting Path, so the command reported success at every Path length tested. Replaced with a program outside the system directory, and spelled out that the current directory is searched first too. - Past 8191 characters cmd.exe ignores Path rather than truncating it, so everything found through Path stops resolving at once while system-directory programs keep working. That asymmetry is what makes the failure look arbitrary, and it is why the probe has to be chosen carefully. - Shims are worth knowing about but do not fix this: `mise activate --shims` keeps the shell's Path short, while running a tool through a shim still builds an environment holding every active tool's directory, so `npm` invoking cmd.exe sees the same long Path either way. Listed with that scope stated. Also describes the v2026.5.18 change accurately — stale inherited install dirs are dropped before the current toolset's are added, rather than mise no longer adding them. Reported in jdx#5830
c78c78b to
c82fcee
Compare
Dismissed because a newer commit was pushed; Greptile will re-review the current head.
…x the test for it (jdx#11642)
From #5830, where the reporter's Windows
Pathexceeds whatcmd.exeaccepts andnpm/npxbreak. Three things in the "Path limits" section were worth fixing before anything structural is decided.The documented test does not work
docs/troubleshooting.mdtells you to runmise x -- cmd.exe /d /s /c "where.exe where"and shows it failing whenPathis too long. It does not fail.where.exeis inC:\Windows\System32, whichcmd.execan still resolve while it is ignoringPathentirely.Measured on Windows 11 26200 / cmd 10.0.26100.8875 — same
Pathfor both columns,Git\cmdappended last:where.exe wheregit --versionThe recommended probe reports success at every length, including where
Pathis being ignored outright. Anyone following the docs would conclude they were fine.The limit is 8191, and it is not a truncation
The same measurement puts the cliff between 8184 and 8239 — the 8191 documented in KB 830473:
That KB's "Applies to" only lists Windows 7 / Server 2008 R2 / 2012 R2, so it is worth stating that it still holds on current Windows 11 — the table above is that check.
Ignores, not truncates: past the limit nothing on
Pathresolves, so the symptom is every command reportingis not recognized, not one tool going missing. The old wording ("too long for certain tools to handle") suggests partial degradation.Shims are now listed, along with what they do not cover
mise activate --shimskeeps the shell'sPathshort — one directory instead of one per tool — and was missing from the list. It is listed now, but deliberately not as the fix, because it does not cover the failure this section is about.Measured on v2026.8.0 with three tools active, this is the environment mise builds to run one of them:
Every active tool, not just the one being run. So a shim hands
npmthe same longPaththat activation would, andnpmshelling out tocmd.exefails identically. The entry states that scope rather than leaving readers to switch and find out.Also noted
Duplicate entries are no longer part of this problem — #10162 (v2026.5.18) stopped install dirs re-accumulating on reactivation, and #11491 (v2026.7.18) collapses exact duplicates in computed environments. On the
Pathpasted in #5830 that is 208 entries / 8261 chars down to 125 / 4738. The section says so, and is explicit that it lowers mise's contribution without raising the ceiling.Docs only — no code, no generated files.
Summary by CodeRabbit
cmd.exe8,191-character limit and that oversized PATH values may be ignored entirely.git, verifying the selected program exists, and avoiding system-directory or current-directory probes.