MemoryRouter
All posts

Goose Chat Recall vs MemoryRouter: What a Miss Means

John Rood··5 min read

A missing answer from goose is not proof that Tuesday's decision is gone. Check which record goose searched before changing memory systems.

That distinction matters when comparing goose Chat Recall with MemoryRouter. One searches goose's session history. The other searches a vault you deliberately populate from supported tools. Connecting the second does not repair the first.

goose already remembers past work

The built-in Chat Recall extension searches previous conversations using keywords. Results are grouped by session and ordered by recency, with date filtering available. Give it a session ID and it can load that session's summary. The documentation also says goose uses Chat Recall automatically when you reference past work or ask something that needs historical context.

The separate Memory extension keeps global notes in ~/.config/goose/memory/ and project notes in .goose/memory/. goose loads those saved memories at session start and includes them in every prompt.

So a new goose session is not inherently cut off from yesterday. For work that happened in goose on this machine, the native tools are the first place to look.

First check whether Chat Recall actually searched

In Desktop, open Extensions and check that Chatrecall is enabled. In the CLI, run goose configure, choose Toggle Extensions, and enable chatrecall.

Then ask for a specific lookup, using a project name or a distinctive term from the earlier conversation. Check the tool result rather than treating a confident answer as evidence that history was searched.

Because the documented search is keyword-based, try the words you actually used. If a date filter is active, check its range. If you already know the session ID, request that session's summary instead of repeatedly rephrasing a broad question.

An extension that never ran and a search that returned no matches are different failures. Neither establishes that you need a new memory service.

An older compacted session has a separate caveat

The current Chat Recall documentation warns that compacted sessions from goose versions before v1.14.0 may not be searchable because the conversation-history storage format changed.

That is a specific compatibility warning, not a statement that all compacted goose sessions lose recall. Establish whether the missing conversation was compacted on an affected version before attributing the miss to that warning.

MemoryRouter is not an archive-repair tool. Adding its extension does not import earlier goose sessions or the built-in Memory files. It cannot retrieve a decision from an old conversation that was never saved into its vault.

Keep the original history while investigating. A successful connection to a new service is not evidence that the old record moved there.

A decision made in another tool needs another destination

Suppose you settled a deployment constraint in Codex, then opened goose to implement it. Chat Recall searches goose sessions. The same repository on disk does not turn a Codex conversation into one of those sessions.

This is the case I built MemoryRouter for. Save a useful decision into a vault, then let another supported assistant retrieve it without copying the conversation. goose and Claude can connect to the same vault even though their local conversation histories remain separate.

That is a choice about where to keep a decision, not a claim that goose lacks memory.

For goose, MemoryRouter is a remote MCP extension using Streamable HTTP and OAuth. It keeps goose on its existing model provider. Merge this entry into extensions in ~/.config/goose/config.yaml:

extensions:
  memoryrouter:
    type: streamable_http
    name: memoryrouter
    enabled: true
    uri: "https://mcp.memoryrouter.ai/mcp"
    timeout: 300

On the first protected tool call, complete browser sign-in and choose the intended vault. A first search requests read access; a first save can open another consent screen for write access. Do not put a Memory Key into the extension's headers. This route uses OAuth.

The goose setup guide covers Desktop installation and authorization details. The MemoryRouter MCP overview describes the shared-vault connection.

There is no MemoryRouter capture-hook package for goose. Searches and saves are model-directed. Ask explicitly when a decision matters, and inspect the call. One OAuth connection uses one vault; use separate vaults and connections for work that must stay isolated.

Test the handoff without borrowing the answer

Use a synthetic decision so no private project data enters the test.

  1. In goose, ask: "Store this in MemoryRouter: the demo project Larch uses a staging-only webhook because live customer events must not enter its test queue."
  2. Confirm that store_memory ran. A queued acknowledgment is not yet proof of searchability; verify the decision with a MemoryRouter search before proceeding.
  3. Open a fresh Claude conversation with MemoryRouter enabled. Its OAuth connection must point at the vault you saved into. Leave the decision and the old transcript out of this conversation.
  4. Ask: "Search MemoryRouter for Larch's webhook decision and explain the reason."
  5. Inspect the search_memories result for the staging-only constraint and its reason before accepting the answer.

If that lookup misses, check the saved memory and the selected vault. Chat Recall's older-session warning does not explain an empty MemoryRouter result, just as a MemoryRouter connection does not fix an older goose archive.

Create a MemoryRouter account and connect the same vault to goose and your next supported assistant before handing off a decision.

All posts