Project memory that agents can write, recall, and you can see and delete

[SiavZ]

Problem

Each provider keeps its own memory, or none at all. Claude Code reads CLAUDE.md, and Codex reads AGENTS.md. Both are instruction files that are shared, committed, and loaded into every turn. Nothing provider-neutral survives a new thread. When you switch providers, or start a fresh thread in the same project, what an agent learned is gone. It might be how to run the e2e suite, the API that looks deprecated but isn't, or the decision you made three threads ago. You end up pasting the same context back in, or asking the agent to grow those instruction files.

T3 Code already gives every provider the same t3-code MCP server, so there is one place to add this for all providers at once. Today that server has thread, project, preview, device, PR, and orchestrator tools, but nothing that persists notes (McpHttpServer.ts L718, McpInvocationContext.ts L11).

I searched Ideas and open PRs for memory, remember and recall and found nothing overlapping. #6737 (a session notes panel) is the closest. It is scoped to a single session and written by the user, not the agent.

Proposed outcome

• Opt-in tools. A new memory MCP capability, off by default, gated by a setting that works exactly like Agent device access (enableAgentDeviceAccess), including the project override. When it is on, agents get three tools:
  • memory_remember
  • memory_recall, lexical, with a bounded result count and character budget
  • memory_forget
• Project-scoped. Memory belongs to an environment-local project, the same way threads do. Project A never sees project B. There is no global store in this proposal. A project holds at most 500 entries.
• Visible and deletable. Settings → Integrations gets an Agent memory toggle beside Agent browser access. With a project selected, it also lists what agents stored, with delete. The toggle is on mobile too.
• One service. A MemoryService holds the logic. The MCP handlers and the two RPCs (list and delete, for the settings UI) stay thin. Scheduled tasks and delegated agents use the same tools.
• Storage. One table in the environment's SQLite. It lives on the environment that runs the agent, so it behaves the same over LAN, Tailscale and Connect. It is not synced across environments.

Out of scope: automatic recall injected into prompts, global or cross-project memory, embeddings or semantic search, importing from CLAUDE.md and AGENTS.md, and syncing between environments. Each would be its own discussion if this lands.

Decisions requested

1. Workflow. Should T3 own a provider-neutral, project-scoped memory that agents write through the t3-code MCP server, opt-in and off by default?
2. Surface. Is Settings → Integrations, next to agent browser access, the right home for the toggle and the list?
3. Scope. Is project-only (no global store) the right first cut?
4. Recall. Is pull-only recall right for v1, where the agent calls memory_recall and nothing is injected into prompts?

Verification plan if approved

• Service tests: remember, recall, forget; project isolation; result, size and entry caps; and denial when the capability is off, all through the real MCP registration. Credential rotation when the setting flips.
• Migration test, plus a headless boot on a fresh database and on a copy of real data.
• Before and after screenshots of the settings toggle and the memory list on web, and the toggle on mobile.

A working implementation on current main is on my fork, about 1.1k lines including tests and docs: SiavZ/t3code v2/agent-memory. I won't open a PR here unless this is approved, and I'm happy to reshape it to whatever scope you prefer.

Written with Claude Opus 5.5 in Jcode.

[chiragmRoado]

+1 this. I would also like if there's a option to sync memory between different machines, like laptop or homelab.

I right now have a manual agent memory sync via git repo, which works, but is quite rough. If t3 implements this, working on same project across different machines will be much easier

[fadymondy]

+1, and a data point from building this. In a T3 fork I added a memory toolkit to the existing t3-code MCP server, so every provider gets the same memory without per-provider setup:

• memory_retain: the agent saves a fact with provenance (thread, provider), scoped to the project.
• memory_recall: hybrid search (full-text + vector) over that project's memories, newest and most salient first.
• memory_forget: removes one memory.
• The user can browse, edit and delete everything in a panel. Nothing is hidden from the user, and it's all in T3's SQLite database, not in CLAUDE.md or AGENTS.md.

In practice the gain is the one described above: a fresh thread, or a switch from Claude to Codex, recalls "how we run e2e here" instead of rediscovering it.

If the direction is welcome, I'd propose a deliberately small first PR:

1. Three MCP tools (memory_retain, memory_recall, memory_forget), project-scoped, using SQLite full-text search only (no embeddings, no new dependencies).
2. A read/delete list under project settings.

Syncing across machines (as @chiragmRoado asked) could come later through existing environment sync, not in the first PR.

@juliusmarminge @t3dotgg, would you approve that scope? Happy to adjust before writing it.

[SwiggitySwerve]

I'd like to propose a deliberately small first step for this: file-based, provider-neutral, and built on the existing t3-code MCP server.

Scope (tools only):

• Two tools: t3_project_notes_read and t3_project_notes_write.
  • Notes are plain Markdown files under <T3 home>/project-notes/<project id>/. They're created on first write and never touch the repo.
  • The project defaults to the caller's thread project.
  • A thread can write only to its own project, and never in plan mode. Outside MCP clients need full access.
  • A write is capped at 6,000 characters and a file at 32,000. Reads are paged.
  • Deleting a project keeps its notes.
• Out of scope for now: search or vector recall, a UI panel, and any change to agent instructions.

It's one focused change: 14 files, mostly the notes service, the two tools and tests. I have it on a branch off current main with typecheck and tests passing.

Questions before I open anything:

1. Are plain files under T3 home acceptable, or should notes live in the database (as @fadymondy suggests) so they sync to connected clients?
2. Discovery: as it stands, agents learn about notes only from the tool list. Would a one-line runtime instruction ("project notes: use t3_project_notes_read") be acceptable, or should that wait?
3. Approval: Codex will likely ask before each notes write, like other write tools. Is that the behaviour you want, or should notes writes be pre-approved since the server already limits them to the thread's own project?
4. Must the see-and-delete UI ship in the same PR as the tools? If so, a read-only list with a delete button in Settings › Project seems like the smallest version.

[St4NNi]

+1, this would be great to have.

What would be nice to add is a way for memory to clean itself up. Agents will store duplicates, facts that go out of date, and entries that contradict each other. And a lot of corrections I give in chat never get stored at all, because the agent didn't think to call remember.

Anthropic has a feature for exactly this in Claude Managed Agents, called dreaming. A scheduled job reads past sessions together with the current memory store. It picks up recurring mistakes and preferences, merges duplicates, and replaces stale or contradicted entries with the latest value. It writes the result to a new store and leaves the old one untouched, so you can review the changes or apply them automatically.

Something similar would fit T3 well as an opt-in setting. Since T3 holds the chat history for every provider, it could dream across Claude, Codex and opencode threads alike. You'd pick the schedule and the model. T3 already has the scheduler, delegation to any provider, and the thread history, so most of the pieces exist. Changes should be reviewable and easy to undo, and it shouldn't silently delete something I wrote myself.

Two other things that would be nice: a global scope for personal preferences that apply to every project, and threads that are already running picking up a correction on their next turn, not only new threads.

[fadymondy]

Following up on my earlier comment, with a concrete offer.

The memory toolkit I described is part of Zekra, a memory service I build and run. It already covers most of what this thread asks for:

• Retain / recall / forget with provenance (thread, provider, project) and hybrid search (full-text + vector).
• Sync across machines (@chiragmRoado's ask). Memory lives in one place, either hosted or self-hosted, so a laptop and a homelab see the same project memory.
• Self-cleanup (@St4NNi's point). Dedup, outdated-fact handling, and gap detection for things the agent should have stored but didn't.
• Notes you can see and edit, so memory isn't a black box.

I'm happy to go either way, whichever fits T3 better:

1. Upstream it. I'd contribute the core into the t3-code MCP server as the opt-in memory capability proposed above: local, project-scoped, off by default. Small PRs, starting with retain/recall/forget on local storage.
2. Pluggable backend. Keep T3's built-in memory local and minimal, and let users point it at an external memory server (Zekra or any compatible one) when they want sync, search and cleanup. T3 doesn't have to own any of that.

Option 2 could also be the long-term shape of option 1: a local default plus an optional remote backend behind the same three tools.

If a maintainer can say which direction they'd accept, I'll start with a small first PR.

[saiteja-madha]

+1

I’m particularly interested in the pluggable backend approach @fadymondy suggested.

My use case is sharing persistent memory across Codex and other agents, multiple projects, and machines. I’d love to connect an existing memory provider like Hindsight or Mem0 rather than have T3 implement its own memory engine.

Ideally, T3 would expose a lightweight, provider-agnostic memory interface, with local SQLite as the default and external backends as an option.

[djgilcrease]

NOTE: This comment was left by gpt-6.1-sol high on behalf of Dj Gilcrease.

A deliberately small external implementation of this request is now released: Shared Project Memory v0.1.0. The full plugin announcement, evidence and limitations is in #23574.

Install https://github.com/digitalxero/t3-project-memory through Settings → Plugins, then opt in per project under Extensions → Shared Project Memory. Agents use the normal plugin MCP tools to remember, lexically recall/search, correct and forget learned knowledge. The authenticated thread supplies project identity; facts survive new threads and provider switches within that environment-local project. Sources, environment/thread provenance, timestamps and recent corrections remain inspectable. Users can edit, delete, clear and export; every project starts disabled, and recall is pull-only and bounded. Private Project Notes are separate, user-authored data and are never read by this plugin or automatically supplied to agents.

This requires the prototype host fork and does not imply upstream approval. Minimum host: djgilcrease/t3code 99c9ae3f3f844e6d6988809a985a44f68ab21543, on t3/create-plugin-system; real repository installation/lifecycle and packaged-worker loading were verified on combined host 5919178852279902d9ef1abbbccf7515bad9d0f1. Merged host PR and merged plugin PR. No upstream implementation PR was opened.

This version uses atomic per-project snapshots and lexical AND matching, capped at 500 facts, twenty recalled entries and a 20,000-character retrieval budget. After actual source inspection and practical tests of both veqlite and RAG-lite, neither was adopted: storage rationale and experiments. There are no embeddings, model downloads or API charges. It intentionally does not implement the cross-machine sync, external memory-provider integration, dreaming/self-cleanup, semantic search or automatic deduplication discussed above. Separate environment/project records stay separate; export is paginated copyable JSON, with no import path.

Disabling project access retains data for user inspection/export/delete. Clearing deletes entries and correction history and disables access. Plugin disable stops commands; removal deletes managed data. Existing exported copies and memory already recalled into a conversation cannot be withdrawn.

Evidence includes green plugin CI on Linux/macOS/Windows, 34 combined-host focused tests, actual repository-URL install and lifecycle checks, normal packaged-worker loading of the published artifacts, public checksum verification, and Linux real-browser inspector/remember/correct/export/clear verification. Release assets and verification receipt include before/after captures. Native Electron/iOS/Android, Linux SEA, and live remote/tunnel/provider turns were not tested; the host PR's known inherited CI failure/queued jobs are disclosed in the full announcement rather than represented as green host CI.