Can I share AI memory across projects without mixing project context?

Yes. Keep reusable preferences in personal scope and project decisions in project-private scope, then query the intended project identity. Cairn.ink Memory links the same project across Claude Code and Codex through the installer's memory ID, rather than matching folder names. Keep shared build rules and current architecture in maintained repository files.

Which context should follow me everywhere?

Start with a simple test: would you want this statement influencing work in a completely different repository? “Explain trade-offs before showing code” is a personal preference. “Use SQLite for this prototype” describes one project. Saving the second as a global preference makes an unrelated project harder to reason about.

Add enough wording to make the intended scope obvious. “For Harbor's offline prototype, use SQLite” is easier to review than “Use SQLite.” The first statement names both the subject and the reason. An assistant can then compare it with a current instruction without treating a temporary implementation choice as your universal preference.

Personal scope is useful for communication style, enduring workflow preferences and background you deliberately want reused. Project-private scope suits working context that matters to you within one project. Shared conventions and facts that the team maintains belong in the repository or its documentation.

Can native instruction files already solve this?

Yes. For a small set of stable rules, files are often enough. The Codex instruction guide describes global guidance under the Codex home and project guidance in AGENTS.md. The Claude Code memory guide describes user-level instructions and project files. Both were accessed on 2026-11-12.

Use a user-level file for your own recurring preferences in that client. Use a repository instruction file when everyone contributing should see the same rule. This gives collaborators an ordinary review path when a convention changes, rather than relying on each person's assistant to remember the latest decision.

A shared private memory service becomes useful when you want selected context to follow you between assistants or computers. Choose it for that continuity, while keeping the repository's maintained instructions easy to find.

How do I set up Cairn.ink Memory for this?

Start with the installer:

npx @cairn-ink/memory setup

Choose Cloud for automatic capture and prompt recall across Claude Code and Codex. With Node 22.16 or later and both CLIs on your path, setup finds the tools and asks about new connections. Fully close both and wait for background work to finish before confirming shared memory. One browser sign-in connects a first paired installation. Reopen the clients and review the four Cairn.ink Memory hooks in Codex /hooks.

Choose Local for free, no-account explicit tools on one computer, without automatic capture or cross-computer sync. The installer registers both clients against one local database and owner. Its optional project binding is a configured identifier; the installer README documents when --project ID can be set.

Cloud saves masked conversation text and sends a masked, length-limited prompt copy for recall. Review the privacy controls before enabling capture for the projects you work on. Treat the choice of storage and processing as part of the setup decision.

How is the same project linked between tools?

Cairn.ink Memory's Cloud installer uses a memory ID to connect the same project across tools. The project boundary is an opaque identity: the plugin derives a code locally using a private key, keeping the derivation key on the device. Project identity is never inferred by an assistant from a folder name.

The installer preserves existing IDs. When two independent IDs exist, it asks you to choose. After successful sign-in and validation, the other key is renamed to a unique backup. Read that choice carefully when combining older installations, because the identity is what makes project context line up.

Matching directory names do not establish matching project identity, and choosing a different memory ID can leave old projects unmatched. Start diagnosis with the intended server, account and installer-linked identity. If personal recall works while project recall fails, inspect those project bindings before copying or resaving decisions.

For Local, follow the configured database, owner and optional project binding. The local core uses an exact namespace for its operations; use its documented binding instead of assuming the hosted personal-plus-project retrieval behavior applies identically to Local.

How do I use personal and project scope deliberately?

In hosted Cairn.ink Memory, personal scope covers your projects. Supplying project_id to recall_memory includes that project's private Memories alongside relevant personal context. Use the trusted integration's project identity, rather than asking the model to invent one from a repository label.

Consider two hypothetical projects. You prefer concise reviews everywhere. Harbor has an offline prototype, while Cedar is a hosted service. Keep the review preference personal and Harbor's offline constraint project-private. In Cedar, ask about its own constraints and use its current repository sources for implementation choices.

When explicitly saving, ask the assistant to show the scope and returned Memory ID so you can inspect the decision it made. A clear request is easier to audit than a broad “remember everything about this project.” Review the Source Receipt to see the text that led to the saved context.

How can I check the boundary with harmless data?

Use a small exercise before relying on the arrangement for real work:

1. Save a harmless personal preference and keep its returned ID.
2. In project A, save a distinct fictional project constraint using the supported project identity and keep that ID too.
3. In fresh sessions for projects A and B, inspect the tool-returned scopes and IDs while asking the same relevant question.
4. Confirm that personal context is available where intended and that the project-specific result belongs to the matching project.

Keep the expected IDs outside the test prompts. If every lookup is empty, first resolve the connection or save failure; an empty result alone cannot demonstrate correct isolation. This exercise checks your configured workflow and helps you spot a scope mistake early.

What should stay in the repository?

Keep supported runtime versions in manifests and CI configuration, contribution rules in maintained instructions, and durable architecture decisions in reviewed documents. Link from AGENTS.md or CLAUDE.md to the relevant source when a reader needs detail. A private reminder can help you find that document, while the document remains the team's maintained reference.

Project-private Memory still belongs to you; publishing a Knowledge Card to a shared collection requires a separate human decision. This separation lets you carry personal context between projects without turning every remembered conversation into team policy.

Use the connection guide to connect your clients and check their intended scope.