# How to share memory between Claude Code and Codex

Connect both coding agents to one self-hosted Keep. A decision captured while
you work in **Claude Code** can become useful starting context in **Codex**—with
working state, provenance, coordination, and Firekeep-mediated evidence
attached.

[Install Firekeep](https://firekeep.ai/claude-code-codex-shared-memory.html#install) ·
[See the handoff](https://firekeep.ai/claude-code-codex-shared-memory.html#handoff) ·
[Read the complete docs](https://firekeep.ai/docs.html)

Self-hosted · MCP-native · One person or a team

Published and updated August 28, 2026 by the Firekeep team.

## The short answer

Give both runtimes an MCP connection to the same Keep.

Firekeep installs a local gateway and configured adapters for Claude Code and
Codex. Both reach the same self-hosted workspace, so selected knowledge and
active work do not end at a model, chat, terminal, or machine boundary. Claude
Code can use its supported lifecycle hooks; Codex uses the same Firekeep tools
through explicit MCP calls.

## Keep native memory. Add what needs to travel.

Claude Code and Codex each have their own ways to carry instructions, project
context, and provider-native continuation. Firekeep does not replace those
systems or merge their private provider histories. It adds an independent layer
for the knowledge and working state you want connected agents to use together.

- **Runtime-native context:** use each runtime's own context, instruction files,
  and continuation features for work that belongs to that runtime.
- **Firekeep:** keep selected decisions, proven fixes, procedures, active goals,
  and documents available across connected runtimes and machines.

The runtime handles the conversation. The Keep preserves what should remain
useful after that conversation ends.

## Install the shared Keep

Run one bootstrap command. It asks who you are and where the Keep server is,
then renders the shipped Claude Code and Codex adapters automatically.

macOS or Linux:

```sh
curl -fsSL https://firekeep.ai/latest/install | sh
```

Windows PowerShell:

```powershell
irm https://firekeep.ai/latest/install.ps1 | iex
```

Then:

1. **Name the agent.** Choose the identity that will be attached to memories,
   sessions, and replay events.
2. **Choose the Keep.** Set one up on this machine, redeem a teammate's join
   code, or connect to an existing address.
3. **Let the adapters render.** The Client Kit configures the shipped Claude
   Code and Codex connections. Restart open agent sessions.
4. **Verify the path.** Run `firekeep doctor` and confirm the server,
   credentials, runtimes, and memory services are healthy.

For a new all-in-one Keep, choose **Set one up on this machine** on an x86-64
Linux host, or through Docker Desktop with amd64 support on Windows or macOS.
To join a Keep your team already runs, choose the join-code path. Codes are
single-use and enroll the machine against the same workspace.

See the [complete installation guide](https://firekeep.ai/docs.html#server) for
server sizing, enrollment, source installation, and troubleshooting.

## Same Keep, different automation

The shared tools are identical. The lifecycle is not.

| Firekeep surface | Claude Code | Codex |
| --- | --- | --- |
| Connection | Configured adapter and the full MCP tool surface | Configured adapter, repository guidance, and the full MCP tool surface |
| Session opening | Supported hooks can open the session with a briefing and prior art | Call `ctx_start_session` explicitly; its response returns prior art through MCP |
| Recall | Direct recall plus prompt-triggered recall through the supported hook path | Call `memory_recall` explicitly when the task should use the Keep |
| Working state | Hooks can assist lifecycle capture; the agent can also call session tools directly | Use `ctx_update` and session tools directly as the work changes |

## A Claude Code to Codex handoff

Imagine Claude Code discovers why a release job fails. The valuable part is not
the chat transcript. It is the diagnosis, the approach that worked, the approach
that did not, and the current state of the task.

1. **Claude recalls.** The session checks the Keep for earlier decisions and
   procedures before changing the release pipeline.
2. **Claude captures.** It records the goal, decisions, progress, and verified
   fix with provenance while the evidence is fresh.
3. **Codex starts.** A later Codex session declares its goal and explicitly
   recalls the release-pipeline history from the same workspace.
4. **The Keep improves.** Codex acts on the result, reports whether it helped,
   and updates the shared working state for whoever comes next.

Say this in Claude Code:

> Recall what our Keep knows about the release pipeline. As we work, preserve
> the decisions and the verified fix—including why the first approach failed.

Then say this in Codex:

> Start a Firekeep session for this goal, then recall what we learned about the
> release-pipeline failure. Use it if it applies and record whether it held.

The configured agents call `ctx_start_session`, `memory_recall`, `ctx_update`,
`memory_learn`, and `memory_feedback` through MCP. You can also name a tool
directly when you want deterministic control.

## More than a memory note

- **Context:** memories, selected documents, reusable skills, and explicit
  session state stay connected to identity and provenance.
- **Coordination:** tasks, handoffs, messages, and renewable Relay leases help
  cooperating agents avoid duplicating the same work.
- **Evidence:** Firekeep-mediated replay, declared outcomes, and evaluation
  receipts give important decisions an inspectable trail.

## It works for one person

Use one Keep for your own Claude Code and Codex sessions across projects and
machines. Your active goals, chosen documents, decisions, and hard-won fixes
remain available to you. If other people join later, Firekeep grows into shared
organizational context without replacing the personal workflow that made it
useful.

## Firekeep Studio is optional

The Client Kit is what connects Claude Code and Codex to the Keep. Firekeep
Studio is an optional desktop workspace that uses your installed Claude Code and
Codex CLIs. Choose which runtime leads, add a fresh read-only reviewer, and turn
important work into a Mission with deterministic local checks, bounded repair,
review evidence, and human acceptance.

[Download Studio for Windows](https://firekeep.ai/latest/studio/windows) ·
[Download the universal Mac installer](https://firekeep.ai/latest/studio/macos) ·
[Read the Studio quick start](https://firekeep.ai/docs.html#studio)

## Frequently asked questions

### Does Firekeep replace Claude Code memory or Codex continuation?

No. Keep using each runtime's native continuation, instructions, and project
context. Firekeep adds a separate self-hosted layer for knowledge and working
state that should travel between runtimes, sessions, people, and machines.

### Does Codex receive automatic Firekeep briefings?

Codex receives Firekeep's MCP tools and repository guidance, but it has no
Firekeep lifecycle hooks. Start and update the session, recall memory, and poll
coordination tools explicitly. A `ctx_start_session` call returns prior art
through its tool response on every runtime.

### Can one person use Firekeep with Claude Code and Codex?

Yes. One person can use a Keep across projects, sessions, tools, and machines.
Add teammates later when the same context should travel between people.

### Do I need Firekeep Studio to share context?

No. The Client Kit connects Claude Code and Codex to the Keep. Firekeep Studio
is an optional desktop workspace for choosing a primary runtime, adding
independent reviewers, and running evidence-backed Missions.

### Where does shared Firekeep data live?

In the self-hosted Keep you operate. A local Firekeep gateway on each connected
machine handles MCP, identity, and routing to that server.

## Related Firekeep guides

- [One self-hosted memory server for every MCP agent](https://firekeep.ai/self-hosted-mcp-memory-server.html)
- [Five months of shared operational memory](https://firekeep.ai/case-study.html)
- [Where AGENTS.md ends and dynamic memory begins](https://firekeep.ai/agents-md-vs-memory.html)
- [How Firekeep measures agent instruction compliance](https://firekeep.ai/instruction-compliance.html)
- [Firekeep day-to-day usage](https://firekeep.ai/docs.html#usage)
- [LongMemEval-S recall benchmark](https://firekeep.ai/longmemeval-benchmark.html)