claude-ops: take the Windows Git Bash figures the hook logging pipeline owes (budget, appends, `ls -t`, late-EOF)

[kyle-sexton]

Summary

Every figure behind #3750 was taken on a Linux CI container. Windows Git Bash is the host .claude/rules/hook-budget.md binds the budget to, and four behaviors the pipeline leans on are documented for it but unmeasured there. The Codex review on #3750 asked for the budget figure; the README says it is owed and the switch stays off by default until it is taken.

Claim	Why it matters	What to run on Windows
The always-on kill-switch read costs about one spawn floor (2.42 ms against 2.08 ms on Linux) on 30 events	this is the cost every consumer pays with logging off; the parallel wall across the 30 producer rows plus the existing hooks is the budget number	the fleet's hook fan-out harness, one PostToolUse and one Stop payload, logging off and on
Concurrent >> appends of one line under 4 KB do not interleave	33 producers can append to one session file in the same second	session-event-log.test.sh's 33-parallel case, then the same shape with 4 KB lines (Linux: zero corruption at 4 KB, 376 of 990 corrupt at 16 KB)
ls -t orders by mtime at one-second resolution	retention's "newest N" and the reader's session scope key on it	two files written in the same second on NTFS; confirm the newer sorts first or document the tie
The late-EOF stall costs one idle slice, not the whole read bound	the producer reads 4 KB slices with a balanced-brace stop and a quarter-bound idle slice	the held-open-pipe case on Git Bash; 262 ms is the Linux figure, the 1 s idle bound the ceiling

Also unmeasured: the peer-reported 11 s cold cli-flag-verify run (Linux: 461.6 ms after #3747).

Fix

Run the four probes on a Windows Git Bash host, record the figures in plugins/claude-ops/README.md beside the Linux ones (the "Hook budget accounting" shape guardrails uses), and either confirm the default-off posture or adjust the slice bound and the retention ordering if a figure demands it.

Acceptance

• README carries dated Windows figures for all four rows.
• The Codex thread on feat(claude-ops): per-session hook logging pipeline, default off #3750 (plugins/claude-ops/README.md line 201) can be answered with numbers.

Related

• feat(claude-ops): per-session hook logging pipeline, default off #3750, perf(guardrails): batch the skill-reference index and answer cli-flag cache hits in-process #3747, perf(scripts): local gate scripts take minutes on Windows Git Bash (check-skill, changelog-parity --check-bump, affected-tests, em-dash purge, check-open-questions --brief) #3717 (local gates slow on Windows Git Bash, the same host).

[kyle-sexton]

This was generated by AI during triage.

Claimed for triage by autonomous lane instance vm-triage-202609050304. Lease expires 2026-09-06T19:40:00Z. This is a triage claim only, not an execution claim; the item stays unassigned and available to the worker lane once briefed.

---

Generated by Claude Code

[kyle-sexton]

This was generated by AI during triage.

Triage verdict

Category: Task (premise confirmed). State: briefed → human-gated. Work class: read-only. Priority: medium.

Verification (2026-09-06, against current main)

The debt is real and is already written down as owed in the product's own documentation. The claude-ops README's section on the per-session hook event log carries, in prose, exactly the admission this issue is chasing: the Linux figures are stated (a 2.42 ms kill-switch read against a 2.08 ms spawn floor, about 5 ms for a 2 KB payload, about 36 ms for a 512 KB one), immediately followed by the statement that Windows Git Bash, the host the hook-budget convention binds to, is unmeasured for these rows, that the parallel-wall figure and the budget comparison it feeds are owed before the switch is recommended on by default, and that the default stays off until they are taken.

The supporting surfaces exist: the producer hook and its test suite ship in claude-ops, and the repo-wide hook latency budget is bound to Windows Git Bash by the marketplace's hook-budget rule.

So this is not a speculative measurement request. It is a documented, self-declared gap with a stated consequence (the switch cannot be recommended on by default until it closes).

Why human-gated rather than agent-ready

A single, unambiguous capability blocker: every figure has to be taken on a Windows Git Bash host, and the value of each one is that it was measured on that host rather than inferred. This lane runs on Linux. There is no brief that lets an agent produce these numbers, and an agent that produced them from a Linux container would be manufacturing exactly the evidence the issue exists to prevent being assumed.

The four probes also need a human at the machine for reasons beyond the OS: the NTFS same-second ls -t case needs a judgment call on whether to document a tie rather than assert an ordering, and the held-open-pipe late-EOF case is an interactive setup.

What the human needs to run, and what each figure decides

Taking them in the order the issue's own table gives them:

1. Kill-switch read cost with logging off, across the observable-event set, plus the parallel wall with the existing hooks. This is the number every consumer pays for a feature they have not turned on, and it is the one the hook-budget convention actually binds. It decides whether the default-off posture is merely cautious or actually load-bearing.
2. Concurrent single-line appends under 4 KB from many producers to one session file. Run the existing suite's high-parallelism case, then the same shape at 4 KB lines. Linux showed zero corruption at 4 KB and substantial corruption at 16 KB, so the question for Windows is where its own threshold sits relative to the line sizes the producer actually emits.
3. Whether ls -t orders by mtime at one-second resolution on NTFS. Retention's newest-N rule and the reader's session scope both key on it. If NTFS ties differently, the honest outcome may be to document the tie rather than to claim an ordering.
4. The late-EOF stall on a held-open pipe. Confirm it costs one idle slice rather than the whole read bound. Linux measured 262 ms against a 1 s idle ceiling.

Also unmeasured and worth capturing in the same sitting: the peer-reported cold run of the CLI-flag verification path, which a peer saw at about 11 s where Linux measures well under a second after #3747. That figure is what would tell you whether the peer report is a Windows-specific regression or a cold-cache artifact.

Acceptance, restated so the outcome is checkable

• The claude-ops README carries dated Windows Git Bash figures for all four rows, recorded beside the Linux ones in the same accounting shape the guardrails budget section uses.
• The prose currently declaring the figures owed is replaced by the figures, or, where a probe comes back ambiguous (the NTFS tie in particular), by an explicit statement of what was observed and why it is not a clean number.
• The default-off posture is either confirmed with the numbers behind it, or the slice bound or retention ordering is adjusted because a figure demanded it. Either outcome closes this; only silence does not.
• The review thread on feat(claude-ops): per-session hook logging pipeline, default off #3750 asking for the budget figure can be answered with a number.

Out of scope

• Changing the default-off posture without the figures. That is the thing this issue gates.
• Re-measuring the Linux figures; they are recorded and are the comparison baseline, not the subject.
• The separate Windows Git Bash slowness of the local gates tracked in perf(scripts): local gate scripts take minutes on Windows Git Bash (check-skill, changelog-parity --check-bump, affected-tests, em-dash purge, check-open-questions --brief) #3717, which shares the host but not the question.

Triage claim released by vm-triage-202609050304.

---

Generated by Claude Code