The Stop guard keys on the working tree, not on the session #3

New issue

Open

opened 2026-09-13 14:45:34 +02:00 by solvreven · 0 comments

solvreven commented

2026-09-13 14:45:34 +02:00

Field report from installing f498b6f on 2026-09-12 into a real, busy repository (Python app, ~1,500 tests, background jobs that write tracked data files, a 120 KB CLAUDE.md).

Environment: Windows 11, Git for Windows (bash 5.3.9, core.autocrlf=true from
the system gitconfig), Python 3.14 (python3 is the WindowsApps alias and works),
Claude Code 2.1.269 → 2.1.270.

How it was checked: the kit's own suite; the hooks driven exactly as
settings.json holds them; and four live headless claude -p sessions reading
the hook_response events. Nothing here was run on Linux or macOS.

The Stop guard keys on the tree, not on the session

git status --porcelain describes the working tree. "This session changed
files" is a claim about the session. They diverge whenever a tree is already
dirty when a session starts: long-lived work in progress, or background jobs
that write tracked files.

What happened in our repo:

The tree had been dirty for days, so the guard blocked on the first stop of
nearly every session, including sessions that only answered a question.
In a live headless run, a pre-existing change was blocked. The model spent a
second turn explaining the change was not its own (num_turns: 2).
The once-per-session marker is spent on that false block, so real work
later in the same session is never prompted. The guard is wrong at the
start and absent at the end.
The mirror case: an uncommitted wiki/ edit left by an earlier session
silences the guard for every later session.

We have switched the Stop hook off in our repo until this changes.

Proposal (untested):

SessionStart writes a baseline keyed by session_id (for example the
git status --porcelain -z output, or a hash per path).
Stop blocks only when paths outside the wiki changed since that baseline
and wiki paths did not.
With no baseline, Stop stays silent.
The marker is keyed on (session, hash of changed paths), so genuinely new
work can prompt again.

Companion issues from the same install: #4 (Windows defects, with a tested patch) and #5 (smaller findings).

Field report from installing **f498b6f** on 2026-09-12 into a real, busy repository (Python app, ~1,500 tests, background jobs that write tracked data files, a 120 KB CLAUDE.md). **Environment:** Windows 11, Git for Windows (bash 5.3.9, `core.autocrlf=true` from the system gitconfig), Python 3.14 (`python3` is the WindowsApps alias and works), Claude Code 2.1.269 → 2.1.270. **How it was checked:** the kit's own suite; the hooks driven exactly as `settings.json` holds them; and four live headless `claude -p` sessions reading the `hook_response` events. **Nothing here was run on Linux or macOS.** ## The Stop guard keys on the tree, not on the session `git status --porcelain` describes the working tree. *"This session changed files"* is a claim about the session. They diverge whenever a tree is already dirty when a session starts: long-lived work in progress, or background jobs that write tracked files. **What happened in our repo:** - The tree had been dirty for days, so the guard blocked on the **first stop of nearly every session**, including sessions that only answered a question. - In a live headless run, a pre-existing change was blocked. The model spent a second turn explaining the change was not its own (`num_turns: 2`). - The once-per-session marker is spent on that false block, so **real work later in the same session is never prompted**. The guard is wrong at the start and absent at the end. - The mirror case: an uncommitted `wiki/` edit left by an earlier session silences the guard for **every later session**. We have switched the Stop hook off in our repo until this changes. **Proposal (untested):** 1. SessionStart writes a baseline keyed by `session_id` (for example the `git status --porcelain -z` output, or a hash per path). 2. Stop blocks only when paths outside the wiki changed **since that baseline** and wiki paths did not. 3. With no baseline, Stop stays silent. 4. The marker is keyed on (session, hash of changed paths), so genuinely new work can prompt again. Companion issues from the same install: #4 (Windows defects, with a tested patch) and #5 (smaller findings).

solvreven referenced this issue

2026-09-13 14:45:37 +02:00

Windows: five install and hook defects, with a tested patch #4

solvreven referenced this issue

2026-09-13 14:45:37 +02:00

Smaller findings from a Windows install: exec bit, CRLF re-install, lint, scaffold count, overhead #5