SessionMunch hooks and MCP do different jobs

“Supports MCP” is a useful statement with a remarkable capacity to grow extra limbs.

It can mean access to a search tool. After travelling through a product paragraph, it can sound as though every conversation is automatically captured and delivered to the next model.

I want SessionMunch to reduce the amount of project reexplaining I do. That requires actual connections, with known behavior. A protocol name is a starting point.

The easiest way to understand the integration is to separate three jobs: capture what the harness exposes, retrieve what the agent asks for, and provide a bounded handoff when a new session begins.

Hooks notice activity

Lifecycle hooks are callbacks supplied by an agent harness. A session starts, the user submits a prompt, a tool finishes, or a session ends; the harness invokes an installed handler.

SessionMunch's handlers turn supported events into bounded capture. Native hook commands can spool locally with stable per-entry idempotency keys. Delivery and end-of-session draining are bounded so a memory service doesn't become an excuse for hanging the coding agent.

At the server boundary, payloads are sanitized and routed into storage. For supported native and generated integrations, capture exclusions run before excluded recognized file-tool events enter the spool or transport. That early boundary is more useful than deleting something after it has already travelled through several logs.

None of this gives a hook access to events its harness doesn't emit.

A true session end is particularly important. Some tools expose only a turn boundary. Treat every completed reply as the death of the session and the memory service will spend its life holding tiny funerals. Where there is no reliable end event, an explicit finalize-session action can be necessary.

MCP lets the agent ask

MCP supplies a tool interface. An agent can search knowledge, read a page, inspect recorded events, write memory, or work with handoffs through the same service.

That is explicit recall. The model decides to call a tool, and receives the result. Merely connecting an MCP server does not make the client stream its whole conversation into that server.

This is the boundary that matters for consumer applications. Claude Code is a coding harness; Claude Desktop is a different client, listed as MCP-only. Codex CLI support does not establish capture from ChatGPT desktop or mobile. Connecting tools to a consumer chat must not be described as automatic recording of those chats.

I would love broad continuity. I still need a supported capture path, readable history source, or explicit import before I can claim it exists.

A door into the memory service is not a microphone in every application.

Startup is a third operation

A startup hook can supply a compact handoff or project brief to the next session. That is how useful context can arrive before the agent remembers to search.

The word “can” is doing honest work. Harnesses differ in whether they accept context from hook output. The support matrix documents cases where capture works but startup output is ignored; those clients need explicit handoff retrieval or another supported delivery path.

Likewise, versions matter. Current Codex CLI exposes a session-end event from version 0.145.0; older versions require the documented finalization fallback. Claude Code's optional assistant-final-turn hook capture is a separate, double opt-in feature. It should not be casually generalized to Codex.

The integration I care about is therefore a collection of concrete behaviors: what gets captured, when finalization happens, what arrives at startup, and what the agent must request. A single green “supported” badge doesn't answer all four.

History is another input

Native transcript import can add visible historical sessions through supported read-only adapters. It preserves sanitized events in the ledger and reports unavailable or unsupported stores instead of silently treating them as empty.

That helps distinguish a hook observation from the richer transcript a harness may keep locally. Deterministic session cards use imported or managed transcript rows when available and cite their ledger events; they omit hook mirrors from that input to avoid duplication. Missing tool-result pairs and coverage limits still matter.

Import also doesn't turn an unreadable consumer-chat store into a supported source. I want to know which history was actually read.

SessionMunch is currently a v0.1.0 release candidate. The public setup path is a source build, followed by explicit integration configuration. The point of doing this work is one shared memory service across supported clients, rather than a separate pile of handoff notes for each agent.

That shared service is useful precisely because the connections are understandable. I can change the model or harness while keeping the knowledge, and inspect the path a claim took to get there. Less reexplaining is the goal. Accurate boundaries are how I get there without building another system I have to explain.

Back to the SessionMunch series.

Sources and setup

References pinned to the implementation used here: support matrix, capture and handoff architecture, MCP reference, and history import. The public quick start covers initial setup.