install.sh: settings.json creation fails on Windows Git Bash (fresh install)

[NestorPVsf]

Summary

On fresh installs run from Git Bash on Windows, the `node -e` block at `install.sh:222-239` that creates `~/.claude/settings.json` from `core/settings.template.json` crashes with `ENOENT`. On upgrade the block is skipped (`settings.json` already exists), so this only affects fresh Windows installs.

Environment

• Windows 11 Pro 10.0.26200
• Git Bash (bundled with Git for Windows)
• Node.js v24.11.1

Reproduction

```bash
SANDBOX=$(mktemp -d)
export HOME="$SANDBOX"
cd /path/to/sinapsis-upstream
bash install.sh
```

Observed

```
node:fs:440
return binding.readFileUtf8(path, stringToFlags(options.flag));
^

Error: ENOENT: no such file or directory, open 'C:\tmp\tmp.Tz11Lcs5qK.claude\settings.json'
at Object.readFileSync (node:fs:440:20)
at [eval]:1:34
...
```

The installer continues (the error is not fatal because the node block is followed by `echo OK settings.json created`, which runs regardless). `~/.claude/settings.json` is never written, so the user gets no hook wiring on a fresh Windows install.

Root cause

The code block (`install.sh:222-239`):

```bash
node -e '
const fs = require("fs");
const template = JSON.parse(fs.readFileSync(process.argv[1], "utf8"));
...
fs.writeFileSync(process.argv[2], JSON.stringify(strip(template), null, 2));
' "$SCRIPT_DIR/core/settings.template.json" "$SETTINGS_FILE"
```

When `node -e 'script' arg1 arg2` runs, `process.argv` layout is `[node, '[eval]', arg1, arg2]` — so `argv[1]` is the eval placeholder, not the template path. The script reads `argv[1]` as if it were the template (gets `[eval]` — treated as literal path that doesn't exist on Unix) or on Windows the path-mangling produces the target `settings.json` path resulting in the ENOENT shown.

Fix

Use `argv[2]` and `argv[3]` instead of `argv[1]` and `argv[2]`. Or (cleaner) bind named args:

```bash
node -e '
const fs = require("fs");
const [,, templatePath, outputPath] = process.argv;
const template = JSON.parse(fs.readFileSync(templatePath, "utf8"));
function strip(obj) { ... }
fs.writeFileSync(outputPath, JSON.stringify(strip(template), null, 2));
' "$SCRIPT_DIR/core/settings.template.json" "$SETTINGS_FILE"
```

Impact

• Fresh install on Windows: silently broken — no hooks wired, Sinapsis never activates.
• Fresh install on Linux/macOS: may also be affected (needs verification) — same argv indexing bug, just different path resolution.
• Upgrade path: unaffected (settings.json already exists, block is skipped).

Discovery

Found while developing PR #9 (Laws tier). The laws tier itself works correctly — this bug is pre-existing and unrelated. Out of scope for PR #9; filing separately.

Suggested priority

P1 / high — fresh install on Windows is a common onboarding path and the failure is invisible to the user (no traceback shown in the installer output's `tail -15`, only surfaces when reading full stderr).

[Luispitik]

I tried hard to reproduce this, and the proposed root cause is demonstrably not what happens — verified on the same environment you report (Windows 11, Git Bash, Node v24.x):

1. node -e 'console.log(JSON.stringify(process.argv))' AAA BBB → ["…\\node.exe","AAA","BBB"]. With -e, process.argv[1] is the first user argument; '[eval]' never appears in process.argv (it's module.filename of the eval context — a different API). So the current code (template at argv[1], output at argv[2]) is correct as shipped.
2. Exact repro of your steps: SANDBOX=$(mktemp -d); HOME=$SANDBOX bash install.sh → exit 0, ~/.claude/settings.json created (1.5 KB) with the hooks wired and the _comment fields stripped.
3. The stack trace is inconsistent with the diagnosis: if argv[1] were '[eval]', the ENOENT would be on the literal path [eval], not on …\.claude\settings.json. That trace only occurs if readFileSync receives the settings path — impossible with the upstream argument order. (I could reproduce your exact trace with a modified script that embeds the paths inside the JS string, where MSYS doesn't path-convert them — which suggests a vendored or locally edited copy, same family as vendor install.sh announces 'sinapsis-learning + skill-router' but never copies skills/ folders #17.) Also install.sh runs under set -e: if the node block failed, the installer would abort rather than "continue", and the OK settings.json created line only prints when node exits 0.

Important: applying the proposed fix (reading argv[2]/argv[3]) would break the installer that works today — argv[2] would be the not-yet-existing settings path and argv[3] undefined.

Could you diff the install.sh you ran against upstream and share it if it differs? Meanwhile, closing as not-reproducible. I'll add defensive guards in a future release (named destructuring of process.argv, an existsSync check on the template with a loud FATAL, and a post-block [ -f "$SETTINGS_FILE" ] assertion in bash) so a wrong invocation fails loudly instead of mysteriously. Thanks for the detailed environment info — it's what made this verifiable.