Repository navigation
bug(slm-frontend): node_modules is mode 644, so vue-tsc, eslint and vitest cannot run at all — #16912's remedy is inert for this tree #17573
Description
Hit while writing two vitest files for #13140. #16912's remedy is in place for both frontends and inert for one of them, and the worktree hook prints a success line either way.
Measured
$ ls -ld autobot-frontend/node_modules
drwxr-xr-x 725 ... autobot-frontend/node_modules <- traversable
$ ls -ld autobot-slm-frontend/node_modules
drw-r--r-- 344 ... autobot-slm-frontend/node_modules <- no execute bit
A directory without its execute (search) bit cannot be traversed, so nothing inside it can be reached at all — not by a shell, not by Node's resolver:
$ npm run type-check # in autobot-slm-frontend
sh: 1: vue-tsc: Permission denied
$ ls node_modules/.bin/vue-tsc
ls: cannot access '.../node_modules/.bin/vue-tsc': Permission denied
$ test -r node_modules/.bin/vue-tsc -> false
$ test -x node_modules/.bin/vue-tsc -> false
This is not worktree-specific. The same denial happens against the path in the main checkout, so vue-tsc, eslint and vitest are unavailable for autobot-slm-frontend everywhere on this host. A worktree only inherits it, because the post-checkout hook links to that directory:
🔗 Linked autobot-slm-frontend/node_modules -> the main checkout's install (#16912)
The link resolves, test -d on it succeeds, and the line reads as a success — while the target cannot be entered. That is the part worth fixing beyond the mode bits: the hook reports a link it never checks is usable.
Why this is more than an inconvenience
#16912 closed on exactly this condition — "a frontend change in a fresh worktree has no local verification at all — not vitest, not vue-tsc" — and its argument is the one that still applies: a test that has never run against the unfixed code is not yet evidence. For autobot-slm-frontend that control is unavailable today, and the worktree mandate means every task runs from a worktree, so this is structural for a whole tree rather than an occasional gap.
What I did not do, deliberately
- No
chmod. The directory belongs to the main checkout, which is read-only to a worktree session and shared with other sessions; changing its modes from here is outside what a task branch may touch. - No
npm install/npm ci. Installing into the codebase is prohibited by the repository's own rules, and it would mask the question of how the directory came to be 644. - I did not look inside it, because the mode prevents it. So I cannot say whether anything within the tree is also wrong — only that it is unreachable. Stated rather than assumed.
I also did not determine how the mode was set (the directory is dated 2026-07-08). That is worth knowing before it is simply corrected, in case a tool is doing it repeatedly.
Acceptance criteria
-
autobot-slm-frontend/node_modulesis traversable, andnpm run type-check/npx vitest runexecute in that project. - Root cause recorded: whether a tool, an installer or a one-off set mode 644 on that directory — so the fix is not re-applied every install.
- The post-checkout link step verifies the target is usable (traversable, and one known binary resolvable) rather than reporting success on a link that resolves. A success line that cannot be false is not a check.
- A change under
autobot-slm-frontend/srccan be type-checked and unit-tested locally, which is tech-debt(frontend): a frontend change in a fresh worktree has no local verification at all — not vitest, not vue-tsc #16912's criterion applied to the second frontend.
Related
#16912 (closed — the same gap for autobot-frontend, whose remedy this defeats), #13140 (the two test files that could not be validated), and the pre-push hook's own frontend phase, filed separately.
Activity
mrveiss commentedon Sep 26, 2026
Third independent reproduction, from a third session
Confirmed again from the main checkout, by a session working only in
autobot-frontend:So the mode is a property of the shared install, not of any one session's environment or sandbox — which is the reading my first report got wrong.
Also worth recording: three sessions have now declined to
chmodit, independently and for the same reason — the directory is shared by the main checkout and every worktree, so one session changing a mode there changes it for everyone. That is not reticence, it is the correct scope boundary, and it means this issue will not be resolved as a side effect of someone's task. It needs the owner.fix(hooks): run each frontend project's own toolchain, not autobot-fr…
fix(hooks): run each frontend project's own toolchain, not autobot-fr…
fix(hooks): run each frontend project's own toolchain, not autobot-fr…
fix(hooks): keep the installed pre-push in step with its tracked copy (…
mrveiss commentedon Sep 28, 2026
Chunking triage — a proposal, not an assignment
priority: low— not applied — and the priority is moot if the recommended move happens first.origin/mainsince 2026-08-14 references this issue.Nothing was relabelled, moved or closed by this pass.
mrveiss commentedon Sep 28, 2026
Chunk triage —
v0.9.2 node plane and deploy. Read-only atorigin/main7adaca8c29; nothing labelled or moved.ls -ld autobot-frontend/node_modules→ traversable, the SLM one not) is a local filesystem state, so no repository change makes an already-wrongnode_modulesright.autobot-slm-frontend. So this is not a host issue despite the host-shaped evidence.node_modulesis already 644, which a developer can reproduce locally. Notv0.9-hostmaterial.priority: lowlooks right: it blocks running two frontend checks locally, not the product.