perf(host): Windows kernel Token leak, one per child-creating process, amplified by hook and Bash fan-out (melo-lap-001, melo-desk-001)

[kyle-sexton]

Summary

Both Windows workstations leak kernel Token objects. Each process that creates a child, while a foreground-lock condition holds, leaves one dead primary token behind until reboot.

• Cause: a Windows kernel defect. Public trace: win32kfull!CForegroundLaunch::_CheckAllowForeground (bentoner/windows-token-leak).

• Upstream status: Microsoft has no acknowledgement or fix through 26200.9550 (KB5124010, 2026-09-22).

• Not the cause: neither Claude Code nor our configuration.

• Amplifiers: leaked tokens grow linearly with the number of child-creating processes. Ours are Claude Code hooks, the statusline, Bash-tool calls, the CI runner, and the ollama tray app.

• Prior capture on melo-desk-001: perf(host): melo-desk-001 process creation costs 1.4 to 4 s system-wide; 3.81M leaked kernel Token objects (~10 GB paged pool) since boot #3715.

• Runbook: plugins/claude-ops/skills/audit-performance/reference/known-performance-issues.md, section "The host-level floor: a kernel Token-object leak".

Numbers

host	build	uptime	Token objects	token-family pool	spawn floor
melo-desk-001 (#3715)	26200.x	2 d	3,811,482	paged pool 9.9 GB total	cmd 1.3 to 1.6 s (14 ms after reboot)
melo-lap-001 (2026-09-23)	26200.9457	69 h	512,049 (about 2.1/s since boot)	Toke 1,062 MB + Se* about 360 MB = about 1.4 GB	bash 10 ms, cmd 10 ms: no penalty yet

The melo-lap-001 pool tags come from an unelevated SystemPoolTagInformation read:

• WC* is about 0 and NtFC is under 1 MB.
• So two other known leaks are not active here: the wcifs leak (WSL 2 Plan 9/DrvFS access leaks Windows kernel pool in wcifs.sys on Windows 11 build 26200 microsoft/WSL#41296, Cowork VM causes persistent kernel pool leak (Toke/File/SeAt) leading to system-wide UI degradation on Windows anthropics/claude-code#91265) and the ntfs leak (ntfs.sys NtFC non-paged pool leak: ~21 GB/hr with WSL2 on Windows 11 26200.x microsoft/WSL#40804).
• About 1.5 GB of the 3.72 GB paged pool is unattributed in the tag table.

Measured leak per spawn

melo-lap-001, N=300 per row, quiet host. Idle-window SD was 18 per 60 s.

command	child-creating processes	leaked tokens / spawn (±band)
usr/bin/bash -c true	0	0.00 (±0.13)
usr/bin/bash -c /usr/bin/true	1	1.04 (±0.13)
usr/bin/bash -c 'x=$(:); (:)'	1	1.04 (±0.14)
usr/bin/bash -c 2 externals	2	2.15 (±0.15)
usr/bin/bash -c 5 externals	6	5.95 (±0.18)
cmd /c "cmd /c exit 0"	1	0.96 (±0.14)
Git cmd/git.exe, Git bin/bash.exe (launchers)	1	0.99, 1.01
gh --version	1	0.98

Leaked tokens equal the number of processes that created a child. Which binary it is does not matter.

Open question: when is it armed?

• Prediction: live ForegroundLockTimeout is 2147483647, and bentoner's model says the leak is always armed at that value.
• Observed here: known creators leaked 1.0 each after 10 to 32 min with no user input, and about 0 to 0.24 when input was recent.
• Live sample: a 10 min window with about 4 creators per second showed a net change of 0.

This rests on three conditions and is confounded with time. If it holds, the leak runs hardest during unattended loops and overnight. The operator A/B (typing, hands-off, screen locked) is listed under Next actions.

Config-side levers (per unit, measured)

• External commands: each one in a bash hook, statusline, or Bash-tool script adds 1 token. Builtins, subshells and $(...) add nothing beyond bash's own 1.
• Launcher shims: Git bin/bash.exe, Git cmd/git.exe, and the uv python.exe trampoline each add 1. Use usr/bin/bash.exe and mingw64/bin/git.exe directly.
• Exec-form hooks: a hook running a binary that spawns nothing adds 0.
• ollama tray app: it respawns ollama.exe about 0.5 times per second, about 13% of observed creators.

Next actions (operator)

• Before the next reboot of either host, capture pool tags in an elevated shell: poolmon /iToke and poolmon /iWC*, with /g for the driver column. perf(host): melo-desk-001 process creation costs 1.4 to 4 s system-wide; 3.81M leaked kernel Token objects (~10 GB paged pool) since boot #3715 missed this capture.
• Run the typing / idle / locked A/B (bash_5ext arm bracketed by null arms) to settle when the leak is armed.
• Run a sampler for 2 h or longer that logs Token count, creators, and input-idle age.
• Decide on ForegroundLockTimeout=0 (bentoner's workaround). Defer until the A/B is done; it lets any application steal focus.
• Reduce fork counts per hook and statusline. This is tracked with the hook fan-out work in this repository.

Upstream

• No Microsoft acknowledgement:
  • release health 25H2 (2026-09-22)
  • KB5124010
  • MS Q&A 5952454: last reply 2026-09-08, not from Microsoft.
• Corroboration: openai/codex#30926 (open).
• Adjacent Claude Code issues that raise creator or console counts: Windows: claude.exe spawns cmd.exe/bash.exe child processes without CREATE_NO_WINDOW, causing visible console flashes anthropics/claude-code#70200, #92583, #76353, #94478.

---

🤖 Generated with Claude Code

[kyle-sexton]

Fan-out reduction tracked in #4373; prior capture #3715.

[kyle-sexton]

Pool-tag capture before reboot (melo-lap-001, uptime 72.5 h)

This is the unelevated SystemPoolTagInformation read that poolmon displays, taken with token-leak/pooltags.py. poolmon itself is not installed on this host (no WDK).

tag	paged live	paged MB	nonpaged live	nonpaged MB
Toke	519,634	1,077	0	0
SeAt	2,091,475	192	0	0
SeTd	519,634	71	0	0
SeDt	513,317	39	8,022	12
SeTl	0	0	519,634	63
Proc	0	0	595	2
WCMs	6	0	4	0
WCfn	0	0	0	0

Totals: 2,344 MB paged and 1,722 MB nonpaged.

• Toke still dominates paged pool. SeTd, SeTl and the paged SeDt allocations track it one to one (519,634 each, SeDt 513,317), which fits whole token objects being retained along with their security descriptors, not a single leaked sub-allocation.
• WC* is about 0, which rules out the Windows container / window-composition tags.
• Growth: 512,049 Token objects at about 69 h (the earlier TOKEN-LEAK.md snapshot), 519,634 now at 72.5 h. That is +7,585 in about 3.5 h, roughly 2,200 per hour during active Claude Code use.
• The ollama tray app was quit after this capture window started, so the creator attribution for the next sampler run will not include it.

Other large paged tags, for context: MmSt 193 MB, FMfn 162 MB, NtfF 135 MB.

[kyle-sexton]

This was generated by AI during triage.

Triage: briefed, human-gated

Category: Task (host-level investigation and operator decisions; not a defect in this repository's code). Priority: priority: medium (assessed default: degrades throughput until reboot but blocks no other work; reboot resets it; melo-lap-001 shows no spawn penalty yet at 69 h).

Verified: the runbook section the body cites exists ("The host-level floor: a kernel Token-object leak" in the claude-ops audit-performance known-performance-issues reference). The leak itself is a Windows kernel defect measured by the operator; it cannot be reproduced or fixed from a repository change.

Why a human must act (capability blocker plus an open decision):

• Every remaining Next action runs on a fleet Windows host: elevated poolmon capture before a reboot, the typing / idle / locked A/B (needs a present operator to type or lock the screen), and a 2 h+ sampler.
• ForegroundLockTimeout=0 is a user-scope registry change with a focus-stealing side effect; the body defers it until the A/B settles, so it is an open operator decision.

Split out: the only repository-side lever (reduce child-creating processes per hook and statusline) is tracked in #4373, which is triaged separately. Prior capture: #3715 (closed).

Done when: the A/B result is recorded here, the ForegroundLockTimeout decision is made and recorded, and the runbook section is updated with the arming condition if the A/B settles it.

[kyle-sexton]

This comes from the 2026-09-29 audit of the Cursor run. Reopened: #5136 added only docs and a probe, and the triage "Done when" is unmet: the A/B result recorded, the ForegroundLockTimeout decision made and recorded, and the runbook section updated with the arming condition if the A/B settles it. This needs the owner on the Windows hosts. needs-human stays.

Operator steps (from the issue's Next actions)

1. Before the next reboot of either Windows host, capture pool tags in an elevated shell (poolmon /iToke and poolmon /iWC*, with /g for the driver column; token-leak/pooltags.py is the unelevated fallback used in the 2026-09-23 comment).
2. Run the typing / idle / screen-locked A/B with the bash_5ext arm bracketed by null arms, to settle when the leak is armed.
3. Run a sampler for 2 h or longer logging Token count, creators per second and input-idle age.
4. Decide ForegroundLockTimeout=0 only after the A/B (a user-scope registry change; any application can then steal focus).

Record results here, then update the section "The host-level floor: a kernel Token-object leak" in plugins/claude-ops/skills/audit-performance/reference/known-performance-issues.md, the single owner of the Token-leak facts.

Fix PR #5313 (draft) deletes the token-leak-amplification probe and its test (they compared pasted constants to themselves and no CI lane ran them) and shrinks the hook-budget README section to a pointer. Per-hook fan-out reduction stays on #4373.

Do not close until steps 2 to 4 are recorded.