CodeEraser 1.7.1
A single distribution-chain fix. On Windows the starter read its own SHA256
wrong, refused a binary that was byte-identical to the pin, and took the whole
plugin face down without printing anything. ce check, ce structure and
ce docdup scores are comparable with 1.7.0: no judgment semantics, axis,
threshold or dimension moved, the index schema stays at 16, the wire stays at
7.1.0, the baseline stays at ce.baseline/2, and no default guard tier moved.
The starter refused its own verified copy
sha_of hashed by filename: sha256sum "$1" | cut -d' ' -f1. GNU coreutils
escapes a filename containing a backslash or a newline and marks that line by
prefixing it with a literal \, so the function returned \<64 hex> — one
character longer than any pin, and equal to none of them.
That is not a hypothetical on Windows. CLAUDE_PLUGIN_DATA is a native path,
so every candidate built from it carries backslashes, and the
ce-1.7.0-x86_64-windows.exe sitting in the data directory — byte-identical to
its pin — was rejected as tampered:
codeeraser: REFUSING on-disk ce — SHA256 mismatch, not running …\ce-1.7.0-x86_64-windows.exe
ce.sh then fail-opened at exit 0, per R3. So SessionStart, PreToolUse and Stop
and the MCP report face all went dead at once, and none of them said why: the
script that would have complained is the one that could not start. The symptom
users saw was an absence — no health line, no .ce/, no guard, and a report
server that would not connect.
The fix hashes through stdin (sha256sum < "$1", and shasum -a 256 the same
way). With no filename in the output there is nothing to escape: both tools
print <hash> -, and a backslash path reads exactly like a POSIX one. The
seventeen bootstrap states pass on Windows, including the tampered-artifact and
stale-core legs that must still refuse.
A second Windows leg, named but not fixed here
The three hooks and .mcp.json start with a bare sh, which Claude Code — a
native Windows process — resolves on the Windows PATH. Git for Windows puts
only Git\cmd there, which holds git.exe and no sh.exe; sh.exe lives in
Git\bin and Git\usr\bin. With no sh on PATH the hooks and the MCP server
never launch, and that failure is silent for the same structural reason as the
one above.
This release records it as a prerequisite in the plugin README rather than
changing the launcher contract. Appending Git\bin to your user PATH is
enough; it holds only bash.exe, git.exe and sh.exe, so it cannot shadow
the Windows find or sort (those are in Git\usr\bin), and appending rather
than prepending leaves bash resolving to the WSL one in system32. Hook
configuration is read at session start, so restart Claude Code afterwards.
Unsigned, as before
Binaries are unsigned; the SHA256SUMS asset and the plugin manifest's pins
are the trust anchor (ADR-007). ce update on a 1.7.0 install reads this tag
and the pins committed on it. A 1.7.0 plugin install picks the new pins up
through /plugin update codeeraser.