Claude Unified Memory Changes What Your Agents Actually Know

On August 25, 2026, Anthropic merged the memory systems behind Claude chat and Claude Cowork into a single, continuously updated store, enabled by default for Free, Pro, and Max plans. The change is convenient for individual users. For engineering teams running Cowork against enterprise repositories, it introduces a context layer that is mutable, per-user, and entirely outside version control.

What Changed and What Did Not#

The Anthropic announcement is precise: memory is now shared across chat and Cowork, and it updates in real time rather than summarizing after a conversation ends. A fact mentioned mid-chat is available to the next Cowork task before that chat window closes. Users can read, edit, or delete memory entries under Settings > Memory, but editing requires going through the UI or a conversational prompt, not direct file modification.

Plan split: memory is on by default for Free, Pro, and Max. For Team and Enterprise, admins control availability and it is off until explicitly enabled. The Register confirmed there is no option to separate memory between chat and Cowork; it is unified or it is off. Claude Code is not included in this rollout and remains a separate context island for now.

The Audit Trail Problem#

Here is the specific risk for teams: Cowork can run tasks in the cloud and on a user's local machine. When it does, it now carries whatever that user has accumulated in months of personal chat context. None of that context appears in the repository. It will not show up in a git blame, a CLAUDE.md diff, or a PR description. If a Cowork session makes a code decision that was quietly shaped by a personal preference the user mentioned six weeks ago in chat, that decision is not reproducible by anyone else on the team, and it is not visible after the fact.

The Next Web noted that the earlier architecture had a natural pause point: memory was written when a conversation ended, which gave users a moment to decide the exchange was not worth keeping. Real-time capture removes that pause. Context accumulates continuously, without a deliberate commit.

AGENTS.md Was Already Not the Whole Story#

The instruction-file situation was already strained. In August 2026, Anthropic closed GitHub issue #6235, which had collected 4,667 upvotes requesting native AGENTS.md support for Claude Code, marked as "not planned." The workaround is importing AGENTS.md content into CLAUDE.md or using symlinks. Shopify's leadership described the resulting split-brain state between coding agents as a "lobotomy." Now add a third instruction source, user memory, that is invisible to the repository entirely.

CLAUDE.md is version-controlled and reviewable. AGENTS.md is version-controlled and reviewable. User memory is none of those things. It is editable by the individual, persists across sessions, and contains whatever Claude decided was worth retaining from every conversation that user has ever had. Three separate instruction sources, with different ownership, different mutability, and no enforced consistency between them.

Engineering teams that built CLAUDE.md files specifically to make agent behavior reproducible now have to reckon with the fact that reproducibility depends on memory state too, and memory state is per-user and opaque to reviewers. The instruction file drift problem covered in managing Claude Code configuration drift in large monorepos describes the version-controlled part of this problem. Persistent memory extends the surface further.

What the Forensic Question Looks Like#

An agent writes a PR. The PR introduces a pattern that contradicts the team's stated architecture. A reviewer asks why. The author is not sure; Cowork suggested it. What did Cowork know when it wrote that? The answer now lives in a memory store the reviewer cannot read, edited by a user who may not remember the original conversation, drawn from a chat session that left no log in the repository.

This is not a theoretical scenario. It is the predictable consequence of giving an agentic system that submits code changes a hidden, mutable, per-user context layer. The question "what did the agent know?" becomes forensically meaningful when the agent's output ends up in production.

What Teams Should Configure Now#

Four concrete steps, in order of urgency for teams where Cowork touches production repositories:

First, confirm plan defaults. If the organization is on Team or Enterprise, memory is off by default and requires admin enablement. Verify this in the admin console before assuming individual users cannot turn it on independently.

Second, treat user memory as a configuration surface, not a user preference. Add a section to internal engineering guidelines that addresses memory explicitly: what users should and should not store, and why. Memory files are short and editable; a documented policy costs almost nothing to write.

Third, require that any architectural or convention decision surfaced by Cowork be traceable to a version-controlled artifact. If Cowork suggests an approach that deviates from CLAUDE.md, the deviation needs a code review comment or a PR note, not just the agent's rationale. The memory that produced the suggestion will not survive a user account change or a memory reset.

Fourth, add CLAUDE.md presence and freshness checks to CI. If instruction files are the authoritative source for agent behavior, treat them as first-class configuration: lint them, verify they are present in relevant directories, and flag stale content. This does not address memory drift, but it at least ensures the version-controlled layer is not silently degrading while the memory layer accumulates unchecked.

Where This Points#

Anthropic's plan split, enterprise off by default, consumer on by default, is a reasonable starting point, but it does not resolve the audit problem for teams whose engineers use personal Free or Pro accounts alongside enterprise tooling. An engineer on a personal Pro plan who also contributes to an enterprise repo is carrying personal memory into sessions that touch shared code. The memory stays off for Team/Enterprise-provisioned accounts; the personal account is a separate question.

Unified memory is not a security vulnerability. It is a governance gap: a new input channel for agentic decisions that sits outside the review infrastructure teams have built around files, commits, and PRs. The engineering controls for the version-controlled layer already exist. The controls for the memory layer mostly do not yet.

Hyrax is live at hyrax.dev.