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.