Funes Coding Agent Memory: Claude Code + Codex Setup

A developer can spend an hour proving why a parser was changed, then lose that reasoning when the next task starts in another agent. Funes indexes agent sessions locally, returns original evidence with provenance, and can share one memory between Claude Code, Codex, pi, and Hermes. The limit is important: Funes retrieves history; your agent still has to decide whether an old decision applies.

This guide covers a practical Claude Code → Codex setup, local-only memory, optional Hugging Face syncing, generic MCP clients, and the checks that keep recalled history useful.

Choose the memory boundary before installing

Start with local memory if you are evaluating Funes or working with sensitive repositories. Bind a Hugging Face dataset only when you need the same history on another machine or across a team.

The Funes security policy says parsing, chunking, embedding, and reranking happen locally by default. Data leaves the machine through funes push or a shared-memory integration that publishes at a session boundary. A Hub-backed memory is a dataset repository, so check its visibility before the first push.

For a first pilot, use local. You can change the binding later by rerunning funes add <agent> <memory>.

Install Funes and seed the first index

The official Funes repository provides a shell installer that detects the platform, downloads a tagged binary, verifies its release checksum, and places the executable on your PATH by default under ~/.local/bin:

curl -fsSL https://huggingface.co/buckets/huggingface/funes/resolve/install.sh | sh

Open a new shell if funes is not immediately found, then check the installation:

funes status

The repository lists tagged binaries for Linux x86_64, Linux aarch64, and macOS Apple Silicon. If your platform is not listed, use the project’s build-from-source instructions rather than assuming the prebuilt installer covers it.

The five-minute bootstrap

Run the following where the agent sessions you want to remember already exist:

funes add claude

For Claude Code, this can build the first index, register the read tools, install integration automation, and keep indexing completed turns. The first pass is text-first and documented as taking about one minute after confirmation. It prioritizes prose and reasoning before bulky tool output. (Funes setup documentation)

Then inspect the state:

funes status

If you need to seed or refresh Claude sessions manually, use:

funes index --harness claude

Without a path, funes index can search the standard session locations for Claude, Codex, pi, and Hermes, including ~/.claude/projects and ~/.codex/sessions. With --harness claude, it limits the scan to Claude Code. The indexing guide also documents a roughly 60-second, text-first budget for no-path refreshes; older sessions and large tool results may need later passes.

Funes indexing is incremental, so rerunning it does not re-embed chunks already written. Explicit transcript paths and Hub trace repositories are indexed in full rather than using the no-path budget. (Indexing details)

Attach Funes to Claude Code

For a local Claude Code memory, use:

funes add claude local
funes status

You can omit local because it is the default. If an HF token is available in the terminal, Funes may offer to configure a user-owned <user>/funes-memory repository; decline that prompt for a local-only pilot.

The Claude integration uses a hooks-only plugin and a separate MCP registration. Funes does not edit Claude Code’s settings.json; its automation indexes completed turns, while a shared-memory configuration adds publishing at session boundaries. (Automation behavior)

Open Claude Code and test a known historical decision instead of judging the setup from installation alone:

Find the previous decision about the streaming parser. Use Funes recall if the repository history does not explain it, and cite the session you used.

A good result points to an earlier passage, identifies its session, and distinguishes an old experiment from the current repository state.

To undo the integration without deleting stored data, run:

funes remove claude

The removal documentation says this removes Funes wiring but preserves the local memory, original transcripts, caches, and published memory.

Attach the same memory to Codex

Once Claude Code is working, add Codex to the same local memory:

funes add codex local
funes status

For a shared Hub-backed memory, use the same repository identifier for both agents:

funes add claude <org>/<repo>
funes add codex <org>/<repo>

Codex has a trust step that is easy to miss. Funes writes its hooks to ~/.codex/hooks.json; inside Codex, run /hooks, review the Funes entries, and trust them. Until the hooks are trusted, Codex skips them, so no new turns are indexed and no memory is published. The documented bound-memory workflow requires Codex 0.151.0. (Codex automation requirements)

Run a real cross-agent handoff test

Use a distinctive decision that exists in one session but not the other:

1. In Claude Code, locate the parser decision and note a distinctive term from the discussion.
2. End the session so the indexing and boundary automation can run.
3. In Codex, ask about that term and request the prior reasoning.
4. Confirm that the response identifies Claude as the source harness and points to the original session or turn.

You can inspect the evidence directly from a terminal:

funes recall "why did we switch away from the streaming parser"

recall returns ranked passages rather than a generated summary. Each hit includes source information and a generated get command; copy that command when you need the surrounding turns.

If Codex returns nothing, check the version, /hooks trust state, funes status, and whether the Claude session predates the integration. Then retry with a distinctive term from the original discussion.

Connect pi, Hermes, or another MCP client

Funes directly supports pi and Hermes alongside Claude Code and Codex. Pi uses extension events; Hermes uses shell hooks, and its per-turn indexing is documented as beta. (Supported-agent details)

For an MCP-compatible client outside those four, run Funes as a local stdio server:

{
  "mcpServers": {
    "funes": {
      "command": "funes",
      "args": ["mcp"]
    }
  }
}

To bind the server to shared memory, add the repository after mcp:

{
  "mcpServers": {
    "funes": {
      "command": "funes",
      "args": ["mcp", "<org>/<repo>"]
    }
  }
}

The MCP documentation exposes recall, get, and status. funes mcp is read-only: it does not index sessions or publish data. Use funes index, funes push, or a supported funes add integration for those jobs.

A memory specified in an individual MCP call overrides the server-level binding. If neither is specified, Funes uses local memory.

Use recall without surrendering evidence

Funes has three distinct workflows:

The documented recall defaults are 8 hits, a 30-result reranked candidate pool, a 30-day recency half-life, and 1 neighboring chunk. (Recall flags and defaults)

A reliable debugging loop is:

1. Run funes recall with the error, component name, or decision phrase.
2. Follow the generated get command for the full turn.
3. Check the retrieved decision against the current branch.
4. Make the change or run the experiment.
5. Recall again using the outcome so the next session can find it.

funes ask is narrower. It retrieves first, then gives the selected passages and your question to Claude or Codex for one answer. The child agent receives no tools, stdin, or MCP servers and cannot retry retrieval after a poor match. Although retrieval is local, the question and recalled passages are sent to the provider configured for the selected agent. The ask documentation therefore recommends funes recall for material you would not send to that provider.

Keep the memory trustworthy and operational

Funes preserves source passages and provenance, but it cannot decide whether every historical workaround still applies.

“Coding agents get way less weird when memory is boring infra: local index, exact provenance, private by default.” — @TheArtemisHunts on X

A small production checklist

Funes redacts credentials during indexing and uses a fail-closed TruffleHog scan before publishing. The push documentation says a missing scanner blocks publishing; if a live credential reaches a remote dataset, rotate it immediately because scrubbing a later commit cannot erase repository history.

Use least-privilege Hugging Face tokens: write scope for machines that publish and read-only scope for recall-only teammates or hosts. Two machines publishing to the same remote memory can also race; the automation documentation does not claim cross-machine serialization.

The practical decision

Use one of these starting points instead of installing every integration at once:

Funes coding agent memory FAQ

Is Funes local?

Funes processes and stores memory locally by default. It is local-first, not automatically local-only: pushing, shared-memory hooks, and ask can send data outside the local process.

Does Funes work with Claude Code and Codex?

Yes. funes add supports Claude Code and Codex, as well as pi and Hermes. Codex memory binding requires 0.151.0 and trusted hooks.

Does Funes index sessions automatically?

After funes add, supported integrations install per-turn indexing automation. The initial bootstrap is bounded, so older sessions and bulky tool results may need later passes.

How do I share one memory between Claude Code and Codex?

Use the same <org>/<repo> argument for both funes add claude and funes add codex. Funes keeps the working index local and publishes the shared dataset at session boundaries.

What if Funes recalls a stale decision?

Inspect it with funes recall, expand it using the generated get command, and check it against the current branch before acting. Rephrase the query when the first retrieval misses.

Does funes ask keep data on my machine?

Retrieval and reranking are local, but ask sends the question and recalled passages to the configured Claude or Codex provider. Use recall for sensitive evidence.

Can I remove Funes without deleting memory?

Yes. funes remove claude, funes remove codex, funes remove pi, and funes remove hermes remove integration wiring while preserving indexed memory and source transcripts.