Claude memory stores reached self-hosted sandboxes on 19 August 2026 with a 15-second sync, not a mount

Summary. Anthropic's release notes for 19 August 2026 say that Managed Agents sessions running in a self-hosted sandbox "can now attach memory stores". The documentation behind that sentence describes something meaningfully different from the cloud behaviour. On a self-hosted environment the store is not a live mount: the SDK's environment worker downloads each store to a directory under /mnt/memory/, reconciles changes at most once every 15 seconds, and runs a final sync at session end that can take up to 30 seconds to flush. A worker that is killed rather than cancelled skips that teardown, loses unsynced edits, and leaves behind a directory that blocks the next session attaching the same store. Four caps apply: 8 memory stores per session, 2,000 memories per store, 100 kB per memory at roughly 25,000 tokens, and no support at all on self-hosted environments on Claude Platform on AWS, which bills in Claude Consumption Units at $0.01 per CCU. The ant CLI worker does not mount memory stores, Windows hosts are not supported, and memory store endpoints take their own beta header, agent-memory-2026-07-22, dated 22 July 2026. Sessions themselves bill at the standard rates of $5 per million input tokens and $25 per million output tokens for Claude Opus 5, or $2 and $10 for Claude Sonnet 5 after the increase scheduled for 1 September 2026 was cancelled.

If you moved Managed Agents onto your own infrastructure for residency or security reasons, this is the feature that finally makes those sessions stateful, and it arrives with operational rules you have to build around rather than discover.

What the cloud does, and what your sandbox does instead

On Anthropic's own infrastructure, a memory store is a workspace-scoped collection of text documents mounted as a directory inside the session's sandbox, which the agent reads and writes with the same read, write, edit, glob and grep tools it uses elsewhere. A note describing each mount is added to the system prompt automatically.

On a self-hosted environment the documentation is explicit that "that directory is not a live mount". Your worker materialises it. The sequence, in Anthropic's own ordering, is: download each attached store to its mount_path under /mnt/memory/ using the work item's per-session secret; add those directories to the file tools' allowed roots, with read_only stores added to the read-only roots; reconcile local and remote changes after tool calls, "at most once per sync interval (15 seconds by default)"; and run a final sync at session end, flushing pending uploads "for up to 30 seconds", then remove the directories it created.

Behaviour	Cloud sandbox	Self-hosted sandbox
Store presentation	Live mount	Downloaded copy under /mnt/memory/
Cross-session visibility of a write	Almost immediately	After both sessions sync, 15s interval by default
Who materialises the store	Anthropic infrastructure	Your EnvironmentWorker
ant beta:worker run support	Not applicable	Not supported, use the SDK worker
Windows host	Not applicable	Not supported, worker requires O_NOFOLLOW
Claude Platform on AWS	Supported	Cannot attach memory stores

That third row is the one people will trip over. Anthropic states that on self-hosted workers "a change written in one session becomes visible to another running session only after both have synced, typically well under a minute at the default interval; sessions on cloud sandboxes see each other's changes almost immediately." Any design where two concurrent agents coordinate through a shared memory file inherits a sub-minute consistency window that did not exist in your cloud prototype.

The killed-worker failure loop

This is the part worth putting in a runbook today.

The worker creates each store's directory when a session starts, "refuses to start the session's work if something already exists at that path", and removes the directory when the session ends. Teardown only runs on cancellation. Anthropic's guidance is direct: stop workers with SIGTERM "and give them at least 30 seconds to exit before any hard kill, because the final upload can take that long. If a worker is killed before its teardown runs, remove the leftover store directory under /mnt/memory/ before the next session that attaches that store; any edits in it that had not synced are lost."

Chain those two facts. A worker killed by an out-of-memory reaper, a Kubernetes terminationGracePeriodSeconds shorter than 30, or a container stop that goes straight to SIGKILL leaves a directory in place. Every subsequent session that attaches that store then refuses to start. And the failure is quiet: Anthropic notes that when a store cannot be mounted, "the worker fails the work item: the session emits no error event and stays idle." You get a hung session, not an exception.

EnvironmentWorker does not install signal handlers itself. You wire them: abort the AbortSignal in TypeScript, cancel the context in Go, cancel the task running run() or handle_item() in Python. If the worker runs inside a webhook handler, hook your server's shutdown rather than taking over its signals. Teams standing up AI agents from pilot to production should treat this as a launch-blocking item, not a polish task.

Conflicts resolve silently in favour of the store

Anthropic's conflict rule is unambiguous and easy to miss: "Conflicts resolve in favor of the store." When the agent changes a memory file that also changed remotely since the last sync, the worker keeps the store's version, overwrites the local file, and logs a warning. The write and edit tool calls "themselves succeed and no error reaches the agent."

So the agent believes it wrote something, the file later reverts, and nothing in the session transcript says so. The remedy Anthropic offers is that the agent "can re-read the file after the sync and make the change again", which only helps if your prompt tells it to.

The read-only case has a matching hole. For a store attached with access: "read_only", the write and edit tools refuse changes, but changes made through bash, a custom tool, or an MCP server you serve from the sandbox "are not blocked locally: they are never synced to the store, and the next remote change to that memory overwrites them." If you need the local copy to stay pristine, Anthropic says to disable the bash tool for that agent and give it no custom filesystem-writing tool, and specifically warns against mounting the store path read-only at the OS level, because the worker itself must create and populate the directory. Anyone thinking about sandbox isolation for coding agents should note that the isolation boundary here is the tool layer, not the filesystem.

One more integrity detail: each store directory contains a marker file named .anthropic-memory-store, and "the worker does not sync a directory whose marker is missing or altered." A cleanup script that wipes dotfiles will silently stop synchronisation rather than fail.

The four caps

Limit	Value	What happens at the ceiling
Memory stores per session	8	Attach fewer, or split by owner and access rule
Memories per store	2,000	Writes to new memories fail, including the agent's file writes to unmapped paths
Size per memory	100 kB, about 25,000 tokens	Anthropic advises many small focused files over a few large ones
Concurrent sessions per host on one store	1	Two sessions cannot mount the same store on one host, they need the same path

The 2,000-memory ceiling deserves attention because of how it fails. Anthropic states that at the limit "writes to new memories fail: both direct memories.create calls and the agent's file writes to unmapped paths. Existing memories remain readable and editable." An agent that has been accumulating one memory per interaction will therefore keep working, keep editing what it already has, and quietly stop learning anything new. The suggested pattern is smaller purpose-built stores, one per user and one for shared domain knowledge, each with its own 2,000-memory budget, and attaching a fresh store with the old one set to read_only once a store outgrows its scope.

The comparison with running your own memory layer is now a real decision rather than a theoretical one, and the trade-offs differ from the managed agent memory options across Mem0, Zep, Letta and Cloudflare and from the broader always-on memory versus retrieval-augmented generation choice.

Security and the default that is not the safe one

Memory stores attach with read_write access by default. Anthropic's own documentation states the consequence: "If the agent processes untrusted input (user-supplied prompts, fetched web content, or third-party tool output), a successful prompt injection could write malicious content into the store. Later sessions then read that content as trusted memory."

That is a persistence primitive for prompt injection, documented by the vendor, shipped on by default. Use read_only for reference material, shared lookups, and any store the agent does not need to modify. The same reasoning that drove per-tool web domain restrictions on Managed Agents, announced the same day, applies to the write side of memory.

Deleting content is not as simple as it looks

Every mutation creates an immutable memory version identified by a memver_ prefix, which is good for audit and awkward for erasure. Redaction scrubs content from a historical version while preserving who did what and when. The constraint: "A version that is the current head of a live memory cannot be redacted. Write a new version first (or delete the memory), then redact the old one."

For a Digital Personal Data Protection Act 2023 erasure request, or an equivalent obligation elsewhere, that is a two-step workflow rather than one call, and it needs to exist in your process before a request arrives. Build and test it now.

India-specific considerations

Self-hosted sandboxes are usually chosen for exactly the reason Indian enterprises choose them: keeping the execution environment and its filesystem inside infrastructure the organisation controls. Memory stores complicate that picture, because the store itself remains on Anthropic's side. Anthropic states plainly that "the memory store on Anthropic's side remains the source of truth", and the worker downloads from it and uploads back to it. The self-hosted sandbox controls where the agent's code runs, not where its long-term memory lives.

If your residency commitment covers agent-written notes about identifiable users, that distinction matters and should be written into the processing record rather than assumed away. Note also that Claude Platform on AWS, which bills through AWS Marketplace in Claude Consumption Units at a fixed $0.01 per CCU, cannot attach memory stores to self-hosted sessions at all, so a marketplace-procured deployment and a memory-store design are currently incompatible.

For cost context on the sessions themselves, Claude Opus 5 is priced at $5 per million input tokens and $25 per million output tokens, and Claude Sonnet 5 at $2 and $10, with Anthropic confirming that the increase to $3 and $15 previously scheduled for 1 September 2026 will not occur. Memory content is read into context, so a store full of large files is a recurring token cost, which is the practical argument behind the 100 kB per memory guidance.

What to do this week

Set terminationGracePeriodSeconds to at least 45 on any pod running an EnvironmentWorker, wire SIGTERM to cancellation, and add a startup check that clears stale directories under /mnt/memory/ before the worker begins polling.

Move every store the agent does not need to write to onto access: "read_only", and audit which agents that process untrusted input still hold read_write.

Alert on idle sessions. Because a mount failure produces no session error event, an idle-session alarm is currently the only signal you will get.

Replace ant beta:worker run in any per-session image with an SDK worker entrypoint that constructs EnvironmentWorker and calls handle_item(), and keep ant beta:worker poll --on-work as the poller.

Fix your beta headers. Memory store endpoints use agent-memory-2026-07-22, session endpoints including attaching a store use managed-agents-2026-04-01, and sending both on a memory store request returns a 400.

What is still unknown

Anthropic has not published whether the 15-second sync interval is configurable, what the upper bound on a store's total size is as distinct from its 2,000-memory count, or whether memory stores will come to self-hosted environments on Claude Platform on AWS. Nor has it stated a retention policy for redacted versions. Until those are documented, design for the interval you were given rather than the one you want.

The hard part of agent memory was never storing it. It is knowing which copy is real.

FAQ

What changed for self-hosted Managed Agents sandboxes on 19 August 2026?

Sessions running in a self-hosted sandbox can now attach memory stores. The SDK's environment worker downloads each attached store into the sandbox at its mount path and syncs the agent's changes back. This requires the Python, TypeScript or Go SDK worker, because the ant CLI worker does not mount memory stores.

Is a memory store a live mount on a self-hosted sandbox?

No. Anthropic's documentation states the directory is not a live mount on self-hosted environments. The worker downloads each store to a directory under the memory path, reconciles local and remote changes at most once every 15 seconds by default, and runs a final sync when the session ends.

What happens if my worker process is killed?

A killed worker runs no teardown, so unsynced edits are lost and the store directory is left in place. The next session attaching that store then refuses to start, and emits no error event, so it simply stays idle. Stop workers with SIGTERM and allow at least 30 seconds.

How are write conflicts resolved?

In favour of the store. When the agent changes a memory file that also changed remotely since the last sync, the worker keeps the store's version, overwrites the local file and logs a warning. The write and edit tool calls succeed and no error reaches the agent, so the loss is silent.

What are the memory store limits?

A session accepts up to 8 memory stores. Each store holds a maximum of 2,000 memories, and each individual memory is capped at 100 kB, roughly 25,000 tokens. At the 2,000-memory ceiling, writes to new memories fail while existing memories remain readable and editable.

Are memory stores available on Claude Platform on AWS?

Not for self-hosted environments. Anthropic states that memory stores cannot be attached to sessions on self-hosted environments on Claude Platform on AWS, which bills through AWS Marketplace in Claude Consumption Units at a fixed rate of $0.01 per CCU. A marketplace deployment and this design do not currently combine.

Which beta header do memory store requests use?

Memory store endpoints use agent-memory-2026-07-22, while other Managed Agents requests, including attaching a store to a session, use managed-agents-2026-04-01. Sending both values on a memory store request returns a 400 error, so replace the header rather than adding a second value.

How eCorpIT can help

Agent memory turns a stateless integration into a system with durable state, an audit trail and an erasure obligation, and the operational rules above are the sort that surface during an incident rather than a design review. Our engineering teams handle worker lifecycle, sync semantics and access scoping as part of taking AI agents from pilot to production. If your self-hosted Managed Agents sessions are hanging with no error event, ask our agent engineering team to review your worker setup.

References

1. Claude Platform release notes, 19 August 2026, Anthropic
2. Using agent memory, Claude Platform docs
3. Self-hosted sandboxes, Claude Platform docs
4. Managed Agents overview, Claude Platform docs
5. Managed Agents tools, Claude Platform docs
6. Events and streaming, Claude Platform docs
7. Pricing, Claude Platform docs
8. Claude Platform on AWS, Claude Platform docs
9. Beta headers, Claude Platform docs
10. Agent setup, Claude Platform docs
11. Redact a memory version, Claude Platform API reference
12. Compliance API, Claude Platform docs

Last updated 23 August 2026.