From 24eb07e477d33d0e62ae5e3dae21ff38c2abf598 Mon Sep 17 00:00:00 2001 From: benjamin beres Date: Mon, 27 Jul 2026 14:19:25 +0200 Subject: [PATCH 1/2] Fix: resolveSlug silently returns "unknown" on Windows MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit `gstack-slug` is an extension-less bash script. On Windows, spawnSync without a shell goes through CreateProcess, which does not honour shebangs: the call fails with ENOENT, stdout is null, the SLUG regex does not match, and resolveSlug returns the literal "unknown". Repro (Windows, git-bash, bun): bun -e 'const {spawnSync}=require("child_process"); const r=spawnSync("C:/Users//.claude/skills/gstack/bin/gstack-slug", {encoding:"utf-8"}); console.log(r.error&&r.error.code, JSON.stringify(r.stdout))' # ENOENT null The impact is worse than a wrong path. Both consumers — gstack-decision-log and gstack-decision-search — then read and write ~/.gstack/projects/unknown/. On the write side that is a single anonymous bucket shared by every repo on the machine. On the read side the directory does not exist, so the search returns an empty list and exits 0: the session is told there are no prior decisions and re-litigates settled calls in good faith. The `?? "unknown"` fallback turned an exec failure into a plausible value, which is why this went unnoticed for so long. `shell: true` does not fix it — cmd.exe has no association for an extension-less file and yields "unknown" too. Naming the interpreter does. Two changes: - Retry via `bash