PreCompact hook never fires on auto-compaction (v2.1.105–v2.1.114, refs #13572)

Summary

PreCompact hook is registered per docs but never invoked on trigger:"auto" auto-compaction. This continues to reproduce on v2.1.114. Exact-symptom match to #13572, which was closed stale (no fix) and locked; the closing bot comment invited a fresh report if the issue persisted. It persists — filing per that invitation.

Feature landed in v2.1.105 (2026-04-13) and the dispatch defect has now shipped unpatched across 10+ point releases (v2.1.105 → v2.1.114). @jeffc-dev's comment on #13572 previously reported the same on macOS v2.1.7, so the defect window extends backwards as well.

Environment

• Claude Code CLI: 2.1.114
• Platform: Windows 11 Pro (10.0.26200)
• Shell: Git Bash (C:\Program Files\Git\bin\bash.exe)
• VS Code: 1.104.3 (x64)
• Context window model: Opus 4.7 (1M)

Configuration

.claude/settings.json registers PreCompact per the official docs format:

{
  "hooks": {
    "PreCompact": [
      {
        "matcher": "",
        "hooks": [
          {
            "type": "command",
            "command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/pre-compact-save.cmd"
          }
        ]
      }
    ],
    "SessionStart": [ ... ],
    "Stop": [ ... ],
    "PostToolUse": [ ... ]
  }
}

SessionStart, Stop, and PostToolUse(Edit|Write|MultiEdit) hooks all fire correctly from the same settings file and run the same .cmd shim pattern. Only PreCompact never triggers.

Expected vs Actual

• Expected: PreCompact fires before each compact_boundary event (especially on trigger:"auto"), giving the hook a chance to snapshot in-flight state before conversation compaction.
• Actual: compact_boundary events land in the session JSONL with no corresponding PreCompact invocation. State written in the turns between the last checkpoint and compaction is lost from conversation context.

Evidence

Single session JSONL at ~/.claude/projects/<project-slug>/<session-uuid>.jsonl:

• Total lines: 2231
• compact_boundary events: 28 (all with "trigger":"auto")
• PreCompact hook fire events: 0

$ grep -c 'compact_boundary' <session>.jsonl
28
$ grep -o '"trigger":"[^"]*"' <session>.jsonl | sort | uniq -c
  28 "trigger":"auto"

Sample compact_boundary line:

{"type":"compact_boundary","content":"Conversation compacted","isMeta":false,"timestamp":"2026-04-17T15:05:25.976Z","uuid":"697caec1-...","level":"info","compactMetadata":{"trigger":"auto", ...}}

Shim is healthy — dispatch is broken. Direct invocation of the same hook shim from a shell writes the snapshot file cleanly and returns exit 0:

$ echo '{}' | .claude/hooks/pre-compact-save.cmd
$ echo $?
0
$ ls -la ~/.claude/terminal-state/compaction-snapshot*
-rw-r--r-- 1 Jowyn 197121 32123 Apr 18 ... compaction-snapshot.md
-rw-r--r-- 1 Jowyn 197121 32123 Apr 18 ... compaction-snapshot-latest.md

So the hook command, shim, bash interpreter, and settings wiring all work when invoked externally. The harness simply does not invoke them on auto-compact. (Manual /compact behavior was not re-tested in this session but #13572 reports manual is also broken.)

Impact

Auto-compaction silently destroys state written in the window between the last user-side checkpoint and the compact boundary. For teams that rely on PreCompact as documented to trigger write-through state saves (task files, active-work snapshots, etc.), the feature is not delivering its contract.

Workaround (FWIW)

Since PreCompact cannot be relied on in any of the v2.1.105–v2.1.114 releases, we pivoted the snapshot path to the Stop hook (which fires reliably every turn) with an mtime-delta throttle — Stop delegates to the same pre-compact-save script as a child process when the tracked file has been modified since the last snapshot. This is a workaround, not a fix: ideally PreCompact fires as documented so snapshotting happens at the actual compact boundary, not at every turn-end.

Ask

1. Confirm whether PreCompact dispatch is broken on trigger:"auto" in current mainline.
2. If a fix has landed in an unreleased build, please note the target version.
3. If this is a known issue tracked elsewhere, happy to close as a dup — but please link, because #13572 is closed-stale and locked and there is no public signal of an active fix.

References

• #13572 — same symptom, closed stale 2026-02-27, locked 2026-03-07, bot invited re-file
• jeffc-dev comment on #13572 — same symptom on macOS v2.1.7 (extends defect window backwards)