[Bug]: Source build on non-NTFS/cloud-synced Windows volumes fails cryptically (pnpm workspace links need junctions)
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 84/100
- Issue type
- Documentation
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- node.js, typescript
- Domain
- build-system, documentation
Research direction
Start with docs/installation.md and the README’s “Build from source” section. Document that Windows checkouts must be on a local NTFS volume because pnpm workspace links require junctions, and mention the affected install failure on cloud-synced, FAT32, exFAT, or network volumes. Done when both source-build entry points clearly state the requirement and workaround.
Written by the indexing model from the issue text.
Description
Issue 2 — Document the local-NTFS requirement for Windows source checkouts
Template: Bug report → Product: Source build or repository tooling (docs gap + cryptic failure)
Title:
[Bug]: Source build: pnpm install fails cryptically on non-NTFS / cloud-synced Windows volumes — workspace links need junctions; requirement is undocumented
Product or interface
Source build or repository tooling
Version
Source @ ae65651 (0.5.1). Node.js v24.18.0, pnpm 9.12.0. Windows 11 x64 (build 26200).
Platform
Windows
Steps to reproduce
- Clone the repository onto a volume that is not a local NTFS disk — in this case a Google Drive desktop-mirrored volume that reports FAT32 (
fsutil fsinfo volumeinfo G:→File system name: FAT32, volume name "Google Drive"). Network shares and exFAT USB drives behave the same way. npx pnpm@9.12.0 install --frozen-lockfile
Expected and actual behavior
Expected: either the install succeeds, or it fails with a message explaining that pnpm workspace links require junctions and therefore a local NTFS volume.
Actual: the install downloads and links ~530 packages, then aborts during linking of the vendored workspace dependency with a bare ENOENT stack that never mentions symlinks, junctions, or the filesystem:
ENOENT: no such file or directory, stat 'G:\…\minimax-code\third_party\pi-mono\packages\agent\node_modules\@earendil-works\pi-ai'
at async Object.stat (node:internal/fs/promises:1038:18)
at async renameOverwrite (…/pnpm/dist/pnpm.cjs:54992:15)
at async forceSymlink (…/pnpm/dist/pnpm.cjs:103483:11)
at async symlinkDirectRootDependency (…/pnpm/dist/pnpm.cjs:143278:26)
The failure leaves an empty …\agent\node_modules\@earendil-works\ directory behind. Rerunning reproduces the identical failure.
Root cause: the root .npmrc sets node-linker=hoisted, so regular dependencies are copied and work fine, but workspace:* links (e.g. @earendil-works/pi-ai in third_party/pi-mono/packages/agent) still require a filesystem junction/symlink. Junctions cannot exist on FAT32/exFAT/cloud-mirrored or network volumes — mklink /J fails with "Local NTFS volumes are required to complete this operation".
Verification of the diagnosis: the same commit cloned to a local NTFS drive installs cleanly (25 s), builds (10.5 s), and passes typecheck, check:source, check:tsconfig, test:smoke, test:byok, test:status-contract.
Suggested fix
- Document the requirement in
docs/installation.md(and the README "Build from source" section): the checkout must live on a local NTFS volume on Windows; cloud-synced or FAT32/exFAT locations fail duringpnpm installat the workspace-link stage. This is especially relevant because "Desktop" folders are commonly redirected to Google Drive/OneDrive on Windows machines. - Optionally, fail fast with a clear message: a small preflight (install script or docs CI check) that detects a non-NTFS/non-local checkout root on Windows and prints "clone to a local NTFS drive" instead of the raw pnpm ENOENT stack.
Redacted error summary
npx pnpm@9.12.0 install --frozen-lockfile
…
ENOENT: no such file or directory, stat '…\third_party\pi-mono\packages\agent\node_modules\@earendil-works\pi-ai'
at async renameOverwrite / forceSymlink / symlinkDirectRootDependency
cmd> mklink /J …\pi-ai …\ai
Local NTFS volumes are required to complete this operation.
Before submitting
- I have searched existing issues.
- I have included my version and removed sensitive information.
- Dominant language
- TypeScript
- Stars
- 1.3k
- Forks
- 141
- Avg merge
- 2h 13m
- Merged PRs (30d)
- 88
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from MiniMax-AI/minimax-code
-
bug cli needs-triage
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
MiniMax-AI/minimax-code#128 · 2 comments ·
-
bug desktop
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
MiniMax-AI/minimax-code#87 · 2 comments · 2 reactions ·
-
bug desktop needs-triage
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
MiniMax-AI/minimax-code#80 ·
-
bug desktop needs-triage
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
MiniMax-AI/minimax-code#66 ·
-
bug needs-triage tui
Difficulty 3/5 1-2 days Newbie friendliness 55/100
MiniMax-AI/minimax-code#340 ·
All issues in MiniMax-AI/minimax-code
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
bug v2
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
modelcontextprotocol/inspector#2458 · 1 comment ·
-
Difficulty 1/5 Under an hour Newbie friendliness 75/100
railmapgen/rmp-gallery#4068 ·
-
Mend: dependency security vulnerability status: needs triage 🕵️♀️
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
carbon-design-system/ibm-products#9907 ·