Three updates to Claude Managed Agents landed this week, and unlike most incremental platform tweaks, all three fix problems teams were already hitting in production. Anthropic's own Claude Platform release notes date them August 19, 2026; the @ClaudeDevs account on X amplified the news a day later, on August 20. This post grounds every claim in the official docs rather than the tweet text alone.
If you've been running agent fleets on Claude Managed Agents — the pattern ABC Legal used to run 50+ agents in production — these are the three changes worth reading before your next deploy.
TL;DR
| What changed | What it fixes | Where it lives |
|---|---|---|
| Memory stores now attach to self-hosted sandboxes | Previously memory only mounted on Anthropic-hosted cloud sandboxes; a self-hosted agent had no persistent memory | EnvironmentWorker (Python, TypeScript, Go SDKs); syncs to /mnt/memory/<store> every 15s by default |
allowed_domains / blocked_domains on web_search and web_fetch | No way to restrict what a Managed Agent could search or fetch — a real prompt-injection and exfiltration surface | Per-tool entries on the agent_toolset_20260401 configs array |
| Redesigned Console session viewer | No visual way to follow a multi-agent session's threads or see cost broken down per thread | platform.claude.com — timeline minimap, transcript grouped by model request, Inspector panel |
Do I need API keys for any of this?
Same as any other Claude Managed Agents feature — you need an ANTHROPIC_API_KEY and the managed-agents-2026-04-01 beta header (memory store endpoints use agent-memory-2026-07-22 instead; the SDKs set this automatically). Nothing about these three updates changes how you authenticate.
Is this only for hosted Managed Agents, or does it touch Claude Code too?
Only Managed Agents. All three live inside the agent_toolset_20260401 toolset, the memory stores API, and the Managed Agents session viewer in the Claude Console. Claude Code's own permission system and a plain Agent SDK call using the Messages API's web_search_20250305/web_search_20260318 tool already had their own, separate allowed_domains/blocked_domains support — this release doesn't touch that path.
Memory finally works on self-hosted sandboxes — why the gap mattered
Self-hosted sandboxes let a Claude Managed Agents session keep tool execution — filesystem, processes, network egress — on infrastructure you control, while Anthropic still owns orchestration and the model calls. Anthropic launched self-hosted sandboxes in public beta on May 19, 2026, with support for AWS Lambda MicroVMs, Cloudflare, Daytona, E2B, Fly.io, GKE Agent Sandbox, Modal, Vercel, and generic infrastructure through a custom "environment worker" process.
The catch, until this week: memory stores — the workspace-scoped documents that let an agent carry user preferences, project conventions, and prior mistakes across sessions — only mounted on Anthropic's own cloud sandboxes. Any team that self-hosted for data-residency or compliance reasons (the exact use case self-hosted sandboxes exist for) had to give up persistent memory to get it, or run a parallel non-memory workflow just for compliance-sensitive work.
As of the August 19 release, that's fixed. Per Anthropic's self-hosted sandboxes documentation:
- The mechanism is different from a cloud sandbox's live mount. On self-hosted infrastructure, the SDK's
EnvironmentWorkerdownloads each attached store to/mnt/memory/<store_name>before the agent's tools run, and periodically syncs local changes back — every 15 seconds by default, tunable viamemory_sync_interval(5-second minimum). - Support is scoped: Python, TypeScript, and Go SDK workers get full support via
EnvironmentWorker; the bareantCLI worker does not support memory stores at all; and memory stores cannot be attached to self-hosted sessions on AWS Claude Platform. - The cap is 8 memory stores per session, same as cloud sandboxes.
- Self-hosted sessions only accept
memory_storeresources —fileandgithub_repositoryresources are rejected with a 400 error, so this doesn't turn a self-hosted sandbox into a general-purpose file-mounting mechanism. - Host prep matters: a POSIX filesystem (Linux, not Windows), case-sensitive storage, and graceful shutdown (SIGTERM, not SIGKILL) with at least a 30-second stop timeout, so in-flight memory syncs complete before teardown.
What this actually unlocks: a team running agents against data that legally cannot leave their network — the exact scenario self-hosted sandboxes were built for — can now give those agents the same learn-across-sessions behavior that cloud-sandbox agents have had. Before this update, self-hosting for compliance meant trading away memory; now it doesn't.
Domain controls on web_search and web_fetch — the exfiltration angle
The second change is narrower in scope but arguably higher-stakes: web_search and web_fetch, the two built-in tools in the agent toolset, now accept allowed_domains or blocked_domains (never both — the API rejects a config entry that sets both with a 400 error).
Per Anthropic's Tools documentation, the config looks like this on an agent_toolset_20260401 entry:
{
"type": "agent_toolset_20260401",
"configs": [
{
"type": "web_search",
"name": "web_search",
"allowed_domains": ["docs.example.com", "arxiv.org"],
"user_location": { "type": "approximate", "country": "US" }
},
{
"type": "web_fetch",
"name": "web_fetch",
"blocked_domains": ["ads.example.com"],
"max_content_tokens": 50000
}
]
}
A few details matter more than they look:
- A listed domain covers subdomains, but not the reverse.
example.comcoversdocs.example.com; listingdocs.example.comdoes not coverexample.comorapi.example.com.www.example.comis treated as its own subdomain — list the bare domain to cover both. web_fetchalso gainedmax_content_tokens, capping how much of a fetched page's content enters context — independent of the domain restriction, useful for keeping a research agent from blowing its context budget on one long page.web_searchalso gaineduser_locationfor localized results, matching the Messages API's existinguser_locationparameter.- IP addresses, bare TLDs, and internal-only suffixes (
.local,.internal,localhost) are all rejected at validation time — you can't use this as an internal-network allowlist; it's a domain-name mechanism. - Multi-agent sessions combine lists, never widen them. In a multiagent orchestration session, a sub-agent is bound by its own domain lists, the lists of whatever agent delegated to it, and the coordinator's current lists — allowlists intersect, blocklists union. A sub-agent can narrow what it can reach, never widen past what its coordinator already permits.
Do domain controls replace needing a proxy or firewall?
No, and this is the detail worth being precise about. Anthropic's docs explicitly note that an environment's own networking settings control the sandbox's outbound traffic — separately from web_search and web_fetch, which run on Anthropic's servers regardless of whether the session is on a cloud or self-hosted sandbox. allowed_domains/blocked_domains only govern those two specific tools. If your agent has bash and makes raw HTTP calls, or if it's on a self-hosted sandbox and your worker executes shell commands with network access, those paths are governed by the sandbox's own network policy, not by this feature. Treat this as tool-level guardrails, not a substitute for actual network isolation.
Why it matters regardless: web_search and web_fetch are the tools most exposed to untrusted content — a search result or fetched page is exactly where a prompt injection payload arrives from. Anthropic's own memory documentation already warns that a memory store attached with read_write access is vulnerable to exactly this: "a successful prompt injection could write malicious content into the store." Domain controls on the tool that's most likely to bring that injected content in reduce that specific attack surface at the source, and they're the kind of thing a compliance review will ask for regardless of whether you've also got a proxy in front of the sandbox.
The redesigned Console session viewer — cost visibility for multi-agent sessions
The third change is entirely in the UI, at platform.claude.com. Per the release notes:
"The session viewer in the Claude Console has been redesigned with a timeline minimap, a transcript grouped by model request, and an Inspector panel for session details and cost, raw events, per-tool statistics, mounted resources, and per-thread activity."
For a single-agent session this is a nicer view. For a multiagent orchestration session — where a coordinator can delegate to up to 20 parallel specialist agents, each running in its own session thread with its own isolated context and conversation history — it's the difference between debugging blind and actually seeing what happened. Before this, understanding which of 20 parallel threads burned the budget, stalled, or made the bad tool call meant reconstructing it from raw event logs.
The Inspector panel's per-thread activity and session cost view is the part that matters most for teams running agent fleets at scale, in the same spirit as the efficiency ratio tracking ABC Legal built for its 50-agent fleet — value delivered against cost to run, reported per agent run. A visual cost breakdown per thread inside the Console gives teams a starting point for that kind of tracking without building custom telemetry first. It pairs directly with the session budget controls Anthropic shipped earlier in August, which let you cap a session's spend and pause it with a budget_reached event once it's hit.
Does the redesign change Managed Agents pricing?
No. This is an observability change, not a billing change — nothing in the release notes description touches how sessions are metered or charged.
What people are asking
Does this fix mean I should move everything to self-hosted sandboxes now? No — the memory gap being closed removes a reason not to self-host if you were already choosing between compliance and memory. It doesn't change the underlying tradeoff: self-hosting means you own the environment worker's uptime, host prep (POSIX filesystem, graceful shutdown), and infrastructure costs. Cloud sandboxes remain the simpler default for teams without a data-residency requirement.
Can I set allowed_domains at the agent level and have it apply to every session? Yes — domain lists are set in the agent's tools configuration at agent creation or update, and sessions inherit them unless a session-level override supplies its own tools. You can also update the lists on an idle session directly.
What happens if I set both allowed_domains and blocked_domains on the same tool? The API rejects the request at creation or update time with a 400 invalid_request_error. Pick one per tool entry.
Is the memory-on-self-hosted-sandboxes change generally available or still beta? Managed Agents overall remains a beta product gated behind the managed-agents-2026-04-01 header (memory-specific calls use agent-memory-2026-07-22). This is a capability addition within that existing beta, not a separate GA milestone.
Related on explainx.ai
- Claude Managed Agents: Dreaming, multiagent orchestration, and outcomes loops
- How ABC Legal runs 50+ Claude Managed Agents as code
- Code with Claude Tokyo: scheduled agents, vaults, dynamic workflows GA
- Claude Enterprise-managed authorization for MCP connectors
- How to restrict what Claude Desktop can access on your computer
- What is an agent harness?
- What is MCP? Model Context Protocol guide
- DoorDash Flux: cloud agents platform, 130k tasks a month
- Slash Fintech cut an $80K AI bill with Claude token cost control
Primary sources: Claude Platform release notes — August 19, 2026 · Self-hosted sandboxes docs · Using agent memory · Restrict web search and web fetch domains · @ClaudeDevs on X
This article is an independent summary for developers on explainx.ai and is not sponsored by Anthropic. Technical details are sourced from Anthropic's official Claude Platform documentation as of August 20, 2026, cross-checked against the release notes dated August 19, 2026 — verify current behavior in the Claude Console and platform docs before production use, since Managed Agents remains a beta product subject to change.