PreCompact hook unconditionally blocks /compact, making it unusable

[chrisreeves48]

Summary

The PreCompact hook in hooks_cli.py:hook_precompact() outputs {"decision": "block"} on every invocation, with no conditional logic and no pass-through path. Because Claude Code cancels the /compact action outright when a PreCompact hook blocks (the user never sees a mid-conversation reminder the way Stop blocks surface), there is no mechanism for the user or the assistant to ever get past the hook. The net effect: any user with the mempalace plugin enabled cannot ever successfully run /compact.

Root cause

mempalace/hooks_cli.py:193-216 (as of v3.0.14):

def hook_precompact(data: dict, harness: str):
    """Precompact hook: always block with comprehensive save instruction."""
    parsed = _parse_harness_input(data, harness)
    session_id = parsed["session_id"]

    _log(f"PRE-COMPACT triggered for session {session_id}")

    # Optional: auto-ingest synchronously before compaction (so memories land first)
    mempal_dir = os.environ.get("MEMPAL_DIR", "")
    if mempal_dir and os.path.isdir(mempal_dir):
        try:
            ...
            subprocess.run([sys.executable, "-m", "mempalace", "mine", mempal_dir], ...)
        except OSError:
            pass

    # Always block -- compaction = save everything
    _output({"decision": "block", "reason": PRECOMPACT_BLOCK_REASON})

The docstring is explicit: "Precompact hook: always block with comprehensive save instruction." But there is no corresponding mechanism for letting compaction proceed afterward — the block message says "Save everything to MemPalace, then allow compaction to proceed" but there is no path to "allow."

Why this differs from the Stop hook

The Stop hook has conditional blocking logic at hook_stop() (~line 134): "block every N messages for auto-save." When Stop blocks, the assistant receives a system-reminder mid-conversation, responds with MemPalace tool calls, and the next Stop doesn't block. That loop works.

/compact can't benefit from that loop because it's a local slash command — when the PreCompact hook blocks, the compact operation cancels immediately, so the assistant never gets a turn to respond and unblock.

Reproduction

1. Enable the mempalace@mempalace plugin in Claude Code.
2. Start any session; have any amount of conversation.
3. Run /compact.
4. Compact fails with:

   Compaction blocked by PreCompact hook: COMPACTION IMMINENT (MemPalace). Save ALL session content before context is lost: ...
   

5. Save everything to MemPalace (diary + drawers + KG facts). Retry /compact. Same failure.
6. There is no sequence of MemPalace writes that will let /compact through.

Expected

After the user (or assistant) has saved recent context to MemPalace, /compact should be allowed to proceed.

Suggested fix

A hybrid approach that preserves the safety intent while being responsive to actual save state:

LAST_WRITE_FILE = STATE_DIR / "last_write.ts"
DEFAULT_COMPACT_WINDOW_SEC = 600  # 10 min

def _touch_last_write():
    """Call from diary_write, add_drawer, kg_add on success."""
    try:
        LAST_WRITE_FILE.write_text(str(time.time()))
    except OSError:
        pass

def hook_precompact(data: dict, harness: str):
    parsed = _parse_harness_input(data, harness)
    _log(f"PRE-COMPACT triggered for session {parsed['session_id']}")

    # existing MEMPAL_DIR auto-ingest stays as-is
    ...

    # Escape hatch: users who explicitly opt out of the safety check
    if os.environ.get("MEMPAL_ALLOW_COMPACT", "").lower() in ("1", "true", "yes"):
        _output({})
        return

    # Pass through if MemPalace has had writes recently
    threshold = int(os.environ.get("MEMPAL_COMPACT_WINDOW_SEC",
                                   str(DEFAULT_COMPACT_WINDOW_SEC)))
    if LAST_WRITE_FILE.exists():
        try:
            last_write = float(LAST_WRITE_FILE.read_text().strip())
            if time.time() - last_write < threshold:
                _output({})
                return
        except (OSError, ValueError):
            pass

    # Otherwise block with instruction
    _output({"decision": "block", "reason": PRECOMPACT_BLOCK_REASON})

Plus a small additional change to the block reason text so users hitting the block know their way out:

If you just saved and want to compact immediately, set MEMPAL_ALLOW_COMPACT=1 in your environment and retry, or wait for the Stop hook to fire another save.

Local workaround

Replace line 216 with _output({}):

-    # Always block -- compaction = save everything
-    _output({"decision": "block", "reason": PRECOMPACT_BLOCK_REASON})
+    _output({})

Reverts on plugin upgrade. The synchronous mempalace mine MEMPAL_DIR at lines ~200-213 still runs, so MEMPAL_DIR-based memories land before compaction. Session-specific context relies on the Stop hook having fired its usual save reminders throughout the session, which in practice it does.

Environment

• Plugin: mempalace@mempalace v3.0.14
• Python: 3.9 (user-level install, ~/Library/Python/3.9/lib/python/site-packages/mempalace/)
• Harness: Claude Code CLI on macOS (Darwin 25.4.0)

Happy to submit a PR against this approach if the design looks reasonable.

[mvalentsev]

Duplicate (again) of #938

This was fixed in #863 (merged 2026-04-15) -- the precompact hook now outputs {} instead of {"decision": "block"}, so compaction goes through immediately after a synchronous mine pass.

Please update to latest version.

[jphein]

Confirming this is addressed by #976 (Felipe Truman, merged 2026-04-25): the MAX_PRECOMPACT_BLOCK_ATTEMPTS = 2 cap in hooks_cli.py is exactly the pass-through path you describe. After two consecutive blocks per session, the hook returns _output({}) and /compact proceeds — no more terminal deadlock at context exhaustion. Per-session state means a fresh session resets the budget, preserving the save semantics for typical use.

Just merged this into our fork today. Thanks for the clean root-cause writeup — the framing here (no mid-conversation reminder on /compact, unlike Stop) made the bug structural-not-cosmetic in a way that matters.

Probably closeable once #976 lands in a tagged release.

[mvalentsev]

@jphein are you stalking me at this point? :)

That's the PR description, not the merged code. During rebase #976 explicitly dropped the hooks_cli.py hunk -- see commits 40d7958 ("remove attempt-cap tests obsoleted by develop's pass-through approach") and 8df944a ("drop dead attempt-cap constant"). Merged file list: backends/chroma.py, mcp_server.py, miner.py, palace.py, tests/test_backends.py, tests/test_palace_locks.py -- no hooks_cli.py.

On develop HEAD, hook_precompact() at hooks_cli.py:646-661 does _ingest_transcript + _mine_sync + _output({}) unconditionally. MAX_PRECOMPACT_BLOCK_ATTEMPTS does not exist in the codebase. The fix that closes this is #863 (merged 2026-04-15).

[jphein]

You're right and I was wrong — apologies.

I quoted the #976 PR description without checking what actually merged. Felipe explicitly dropped the attempt-cap during the develop rebase: 40d7958 removed the tests ("they would always fail because hook_precompact now mines synchronously and passes through unconditionally") and 8df944a removed the constant ("the attempt-cap constant was orphaned"). Current hook_precompact() on develop is pure #863 logic — ingest, sync mine, _output({}).

So the correct attribution: this is fixed by #863 (merged 2026-04-15, @mvalentsev), and the issue is closeable as already-resolved.

Thanks for the catch and the patience — won't make the same mistake twice.

[jphein]

Closing as completed — completing what should have followed my apology comment.

Per @mvalentsev's correction above, the actual fix is #863 (merged 2026-04-15 in ecd44f7), not #976. hook_precompact() on develop now does _ingest_transcript → _mine_sync → _output({}) — pass-through, no block decision. Verified unchanged on upstream/develop HEAD.

Sister issue #955 (same symptom, different reporter) just closed with the same attribution. The fix has shipped in v3.3.1 (2026-04-18), v3.3.2, and v3.3.3 — pip install -U mempalace resolves it.

Thanks @chrisreeves48 for the well-structured writeup, and @mvalentsev for catching my misattribution.