mirror of https://github.com/garrytan/gstack.git
699c0f48db
`isExecutable()` tested `access(X_OK)` alone. That is TRUE for directories — they
carry the execute/traverse bit on POSIX and pass the check on Windows too — so
binary discovery accepted a directory as the browse binary.
It bites on a stock global install. `~/.claude/skills/browse` is the skill's own
docs folder and contains nothing but SKILL.md, but it sits on one of the probed
paths, passes X_OK, and wins. From then on every browse invocation runs a
directory as a program and fails with an EMPTY error string, which make-pdf
surfaces as:
[1/5] Checking browse binary... OK (C:\Users\...\.claude\skills\browse)
[2/5] Launching Chromium... FAIL
Chromium failed to launch: browse newtab exited 1:
Note the first line reports the wrong path as OK, so the output actively points
away from the cause. Setting GSTACK_BROWSE_BIN worked around it, which made it
look like a discovery-order problem rather than a type-check problem.
Fix is one `statSync(p).isFile()` before the access check.
Tests: 2 added, both failing before this change and passing after. The first
asserts the precondition explicitly — that the directory really does pass
`access(X_OK)` — so the test documents WHY the bare check was wrong rather than
just pinning the new behaviour. The second reproduces the exact shape: a
directory named `browse` containing a SKILL.md.
|
||
|---|---|---|
| .. | ||
| e2e | ||
| fixtures | ||
| browseClient.test.ts | ||
| coverage-gaps.test.ts | ||
| diagram-prepass.test.ts | ||
| image-policy.test.ts | ||
| pdftotext.test.ts | ||
| render.test.ts | ||