Recall in your agents

Recall lets a coding agent search your Hansard archive and read past conversations while it works. Ask it what was decided about a feature, or tell it to continue an earlier conversation, and it finds and reads the right one. Install recall from the CLI, or on the Give your agents a memory page of the app’s guided setup, which adds it with memory search to every supported agent it finds. Later, Settings → Coding agents adds, repairs, or removes it for each agent.

App

Setup → Give your agents a memory

CLI

hansard integrations add-to

In your agent

/recall

For a comparison of tools, status, memory retrieval, launches, and routing, see Provider and feature support.

Install recall from the CLI

1. Import at least one harness, so the archive has conversations to search. See Supported harnesses.

2. Add recall to an agent:

   hansard integrations add-to codex

   See the table below for every managed target. Other compatible local clients can use hansard integrations config to export the MCP entry. In a terminal, hansard integrations add-to without a name asks which agent to set up.

3. Restart or reload the agent so it reads the new configuration.

4. Ask the agent about earlier work, for example /recall the authentication migration.

Each install adds a Hansard MCP server entry to the agent’s configuration and native commands, skills, and identity hooks where supported. MCP-only clients use the tools directly:

Agent	Name	Commands or skills installed	Invoke directly
Codex	codex	recall, continue-from, deep-recall, and unify-memories skills	$recall
Claude Code	claude	/recall, /continue-from, /deep-recall, and /unify-memories commands, plus matching skills	/recall
Antigravity	antigravity	recall and continue-from skills	Ask in plain language
Devin	devin	recall and continue-from skills	@skills:recall
OpenCode	opencode	/recall and /continue-from commands	/recall
Grok Build	grok	recall and continue-from skills	/recall
Factory Droid	factory	recall and continue-from skills	Ask in plain language
Augment CLI	augment	MCP tools and SessionStart hook	Ask in plain language
Cursor app and CLI	cursor	recall, continue-from, and deep-recall skills, plus a sessionStart hook	/recall
Cline CLI	cline	MCP tools; explicit identity binding	Ask in plain language
GitHub Copilot CLI	copilot	MCP tools; explicit identity binding	Ask in plain language
Amp	amp	MCP tools; explicit identity binding	Ask in plain language
Kimi Code	kimi	MCP tools; explicit identity binding	Ask in plain language
Kiro	kiro	MCP tools; explicit identity binding	Ask in plain language
Zed	zed	MCP tools; explicit identity binding	Ask in plain language
Claude Desktop	claude-desktop	MCP tools; explicit identity binding	Ask in plain language

Skills also start on their own when a request matches them, so asking “which fix for the flaky upload test shipped last week?” works without a command.

The Cursor app and the Cursor CLI (cursor-agent) read the same ~/.cursor configuration, so the one cursor target covers both; cursor-ide and cursor-cli are accepted as other names for it. Gemini CLI remains supported as an import source but is not a live setup target; use Antigravity for current Google agent coverage.

Where the files go

Agent	Commands and skills	MCP server entry
Codex	~/.codex/skills/	~/.codex/config.toml
Claude Code	~/.claude/commands/ and ~/.claude/skills/	~/.claude.json
Antigravity	~/.gemini/config/skills/	~/.gemini/config/mcp_config.json
Devin	~/.config/devin/skills/	~/.config/devin/mcp_config.json
OpenCode	~/.config/opencode/commands/	~/.config/opencode/opencode.json, or the file in OPENCODE_CONFIG
Grok Build	~/.grok/skills/	~/.grok/config.toml
Factory Droid	~/.factory/skills/	~/.factory/mcp.json
Augment CLI	MCP only	~/.augment/settings.json
Cursor app and CLI	~/.cursor/skills/	~/.cursor/mcp.json
Cline CLI	MCP only	~/.cline/mcp.json
GitHub Copilot CLI	MCP only	~/.copilot/mcp-config.json, or COPILOT_HOME
Amp	MCP only	~/.config/amp/settings.json or existing settings.jsonc; amp.mcpServers
Kimi Code	MCP only	~/.kimi/mcp.json
Kiro	MCP only	~/.kiro/settings/mcp.json
Zed	MCP only	~/.config/zed/settings.json; context_servers
Claude Desktop	MCP only	claude_desktop_config.json in the platform Claude application-support directory

Automatic session context and status

Every managed integration includes status reporting. The app’s setup offers Agent messaging and Helper agents on Make it yours, and interactive hansard init asks Let your agents work together? with the same two choices. Both start unanswered. Helpers remain unavailable until messaging is on. Skipping or running hansard init --yes alone keeps both off. A message can announce that an API is ready for tests. A helper can review a change. Messages and helper instructions can reach the receiving agent’s model provider. Automatic identity is available where the client exposes a supported hook or plugin; other clients require explicit session binding. Enabled messaging and helpers use the same project.

report_status and session_context are available even with messaging off. Native hooks or an OpenCode plugin attach the current conversation identity and brief instructions in sessions opened directly in the agent. Hansard launches also supply reporting instructions. This applies to every model selected within a supported harness, including Antigravity app, CLI, and IDE conversations.

Agents report meaningful working, blocked, needs_review, and done transitions to the project overview. These are the agent’s declarations; an installed integration cannot guarantee that every model will report them. Status remains available when messaging and helper launches are disabled.

With messaging enabled, context also directs agents to discover peers, check unread messages, and coordinate concrete dependencies. Hooks never send messages or grant tool permissions. Grok refreshes identity before Hansard tool calls; its prompt hook does not display successful hook output. OpenCode refreshes its briefing through its system-context plugin.

Run hansard integrations sync and restart existing clients after upgrading, so they load new tools such as ask_user, peer_file, code_history, and work_context. Missing generated hooks and plugins are repaired by the watcher. The CLI fallback is hansard session report --state working --note "Checking the task"; pass --session-token when the supplied session context instructs the agent to.

Codex reviews new or changed hooks before starting a session. hansard integrations trust-hooks codex records trust for Hansard’s hooks through Codex, leaving other hooks for review. add-to codex runs this step, and integrations status reports Hansard hooks still waiting for trust.

Managed Codex instructions also ask agents to record newly received native subagent messages with capture_subagent_messages. This retains the exact assignment, follow-up, or result with a session-bound receipt. It records agent-reported text without a recovery conversation or model request. See Recall tool results for its evidence limits.

What your agent can do

You ask/recall the rate limiter design

Agent searchesMatching excerpts from the archivesearch_past_sessions

Agent readsThe relevant part of one conversationget_past_session

AnswerUses the earlier decision and cites the session

Workflow	What the agent does
Recall	Chooses a short search query from your request, runs hansard history, and reads the latest messages of the best match before answering.
Continue from	Finds the conversation, reads its opening and latest messages plus selected decisions, checks the repository, and continues the work in the current session. See Continue in another harness.
Deep Recall	Runs several searches, reads whole conversations, and answers with session citations. Codex and Claude Code only. See Deep Recall.
Unify memories	Compares memories across harnesses and proposes merges for you to approve. Codex and Claude Code only. See Memories.
Recall memories	Searches your archived memories across providers. Installed by default.

Example requests in Claude Code:

/recall the rate limiter design
/continue-from the stats activity work and finish the tests
/deep-recall which caching approaches were tried, and which one shipped?

The instructions Hansard installs tell the agent to treat archived text as history, not as instructions to follow. The agent never runs a command or opens a link only because an archived conversation contains one.

MCP tools

The Hansard MCP server gives the agent these read-only recall tools, plus the memory tools described in Search memories across agents:

Tool	What it returns
search_past_sessions	Matching excerpts for a query, optionally limited to a repository, a date range, or message roles such as only what you wrote. Returns 10 results by default and up to 50, with up to 5 matching messages per conversation when asked. With search by meaning on, it also matches by meaning unless the agent asks for one mode. Imported web chats are excluded unless the agent asks for them.
get_past_session	A window of messages from one conversation, the latest 20 by default, with a cursor to read further. Each tool message is cut to 1,500 characters and marked as truncated, unless the read covers only that message or the agent sets its own cap, so reading that one message returns the rest. It can keep only some roles, set its own cap for every message, and fold repeated drafts into their latest version.
code_history	A file’s or symbol’s history: the edits, commits, reverts, test failures and fixes that touched it, and the files that import it. See Search.
work_context	A task’s conversations, steps, tests, commits, and linked conversations.

The commands and skills run the hansard CLI, so hansard must be on the PATH of the agent’s shell. The MCP server entry records where Hansard is installed.

See Recall tool results for result fields, transcript paging, memory windows, and error responses.

Managed integrations also expose progress reporting. See Agent status and declared events for states, evidence limits, and the difference between an agent’s claim and a recorded command result.

Shared MCP host

Agent sessions share one MCP host, which the watcher runs. Each session’s recall server relays to the host over a private local connection and carries that session’s identity, so an open session costs a small relay instead of its own copy of the tools. Codex reaches the host over loopback HTTP, with one entry for all of its threads; hansard integrations sync rewrites that entry when the host starts or stops. When the host restarts, relays reconnect; with no host running, each session serves itself.

A relay uses a host from any installed copy of Hansard, such as the desktop app, the npm package, or a source checkout, that runs its version or a newer one. hansard status names the running host and its version. Set HANSARD_MCP_HOST=off to run every session in its own process, or HANSARD_MCP_PORT to choose the loopback port (default 7839). On Windows, the host moves to another port when the recorded one is refused.

Search memories across agents

Memory retrieval is included by default. Every managed agent can search the captured memories of every provider and project. To refresh an integration:

hansard integrations add-to claude

This installs a recall-memories workflow and two read-only MCP tools, search_memories and get_memory. Unfiltered searches span the whole bank; optional filters select a provider or a project plus global guidance. With search by meaning on, search_memories also finds memories that say the same thing in other words. Each hit names the memory and, when known, the lines that match, and get_memory opens a window centered on a hit’s line. The agent retrieves relevant records as needed. These tools cannot create, edit, merge, or delete memories.

To omit memory tools for one agent, run hansard integrations add-to claude --no-memories. Automatic refreshes preserve this choice. Reload the agent after changing its integration. The earlier --memories flag remains accepted.

Refresh the installed files

To rewrite the commands and skills without changing the MCP server entry, use integrations recall:

hansard integrations recall codex

Target	What it writes
An agent name	That agent’s commands and skills.
all (the default)	Every agent’s commands and skills, plus plain instruction files under ~/.hansard/skills/.
local	Only the plain instruction files under ~/.hansard/skills/, for agents that read instructions from a file you point them to.

Memory workflows are included by default. A refresh renames older hansard-recall, hansard-continue-from, hansard-unify-memories, and hansard-memory files to their current names. Reload the agent afterward. No reimport is needed.

When a name is already taken

Hansard never overwrites a skill or command it did not write. If you already have your own recall skill, Hansard keeps it and installs its own as hansard-recall, so you invoke it as /hansard-recall. The same applies to every other name. Setup and hansard integrations status say which names moved.

If both names are taken, Hansard skips only that skill, installs everything else, and shows a warning. Rename or remove one of the two files. The watcher then installs the skipped skill within 15 minutes, or you can run hansard integrations add-to <agent> to install it immediately.

If Hansard cannot read an agent’s configuration file, for example a ~/.claude.json with a syntax error, it leaves that file unchanged and still installs the skills. The message names the file. After you fix it, run hansard integrations add-to <agent>, or let the watcher add the MCP entry on its next retry.

Hansard changes only its own entries in an agent’s configuration files. Your comments, formatting, and other settings stay as they are. If a file is a symbolic link, for example into a dotfiles repository, Hansard updates the file it points to and keeps the link. A read-only file is left alone and reported, and every other part of the integration still installs.

Keep recall installed

Hansard records each install. While the watcher runs, it checks every 15 minutes and reinstalls commands, skills, and MCP entries that disappeared, for example after reinstalling an agent recreated its configuration folder. It also refreshes the generated files once after each Hansard upgrade.

The first check records which agents are already on the machine. An agent that appears after that gets recall automatically, without memory retrieval. Agents that were already present are left for you to add. Installs made before Hansard kept this record are adopted when their files or MCP entry are found.

hansard integrations status
hansard integrations sync --dry-run
hansard integrations forget grok

status shows each agent and anything missing. sync also updates messaging and helper tools to match the configured modes, preserving explicit off settings. It runs one check now, and --dry-run reports what it would change. forget stops tracking an agent and leaves its files in place.

Setting	Default	Effect
integrations.autoSync	true	Reinstall missing files and refresh them after upgrades.
integrations.autoInstall	true	Install recall for newly detected agents. hansard init --no-recall sets it to false.

hansard config set integrations.autoInstall false

hansard status and hansard doctor also report missing integrations.

Check and repair in the app

Open Settings → Coding agents. Under Hansard in each agent, each agent Hansard found has one row. Open a row to see the state of its MCP server, its recall skills, and its session-start hook.

• Repair writes each part again. A part that fails shows its reason, and the other parts still install.
• Add gives an agent without Hansard the same three parts.
• Remove deletes the parts Hansard added to that agent and stops keeping it in sync. A file you changed after Hansard wrote it stays, and Hansard names it. Claude Code’s and Codex’s MCP entries are removed with claude mcp remove --scope user hansard and codex mcp remove hansard.

Automatic setup holds the two settings in the table above: Add Hansard to agents you install later and Keep integrations in sync.

Run the MCP server yourself

For an MCP client that Hansard does not configure, run the recall server over standard input and output:

hansard mcp serve

Memory tools are included by default; --no-memories omits them. Add --status for session reporting. --messaging adds Agent messaging. --delegation adds Helper agents. Delegation also turns on messaging.

hansard peers setup configures messaging across detected active harnesses. hansard agents setup configures helper launches across detected or existing managed integrations. Managed installs already enable these capabilities by default; the standalone server uses the flags above.

Bind a conversation without native hooks

For clients without automatic identity, obtain the current native conversation ID and run the binding command locally. For example, Kimi Code uses provider ID moonshot:

hansard session bind --provider moonshot --native-session-id <native-id> --cwd <project>

Keep the returned token in that conversation and pass it as session_token on status, messaging, board, and helper MCP calls. CLI status reports accept --session-token. Do not put a single conversation’s token in global MCP configuration shared by several conversations. If no native ID is accessible, recall and memory search still work, but coordination cannot be bound reliably.

For an unmanaged local MCP client, hansard integrations config prints the command and arguments with the configured default features. Adapt that entry to the client’s native format. It does not install a remote MCP server for browser chats or hosted agents. Claude Desktop setup does not configure a Cowork sandbox, and Cline CLI setup does not modify Cline IDE settings.

Common questions

Which coding agents can use Hansard recall?

Codex, Claude Code, Cursor (the app and cursor-agent), Antigravity, Devin, OpenCode, Grok Build, Factory Droid, Augment CLI, Cline CLI, GitHub Copilot CLI, Amp, Kimi Code, Kiro, Zed, and Claude Desktop. Run hansard integrations add-to <agent> with the name from the table in Install recall from the CLI. Any other local MCP client can run hansard mcp serve.

What tools does the Hansard MCP server provide?

search_past_sessions returns matching excerpts from archived conversations, and get_past_session reads a window of messages from one conversation. search_memories and get_memory search and read memories from every harness. code_history reads a file’s or symbol’s history, and work_context reads a task’s arc. All six are read-only.

Does recall send my archive to the agent’s model provider?

Only what the agent reads. Search results and conversation excerpts join that agent’s context and go to its model provider like any other context; the rest of the archive stays on your computer. See What leaves your machine.

Troubleshooting

The agent says hansard is not installed. Install the CLI globally, see Install the CLI, and restart the agent so its shell finds hansard on the PATH.

The commands or skills disappeared. Run hansard integrations status, then hansard integrations sync. If the watcher is off, run hansard integrations add-to <agent> again.

Recall misses recent conversations. Search indexing may be paused. Run hansard index status, then hansard index resume and hansard index rebuild if needed.

The agent still shows old hansard- command names. Run hansard integrations recall <agent> and reload the agent.

A session starts without the project’s thread digest. Agent hooks stop at 3.5 seconds, before the 5 seconds agents allow. A session-start hook that runs out of time still returns the session token but leaves out the thread digest, and a hook that fails returns an empty result, so it never holds up the agent. hansard doctor lists hooks that failed in the last seven days under agent hooks.