zed-industries/zed · error · anyhow::Error

cannot authorize network access to {host:?}: {error}

Error message

cannot authorize network access to {host:?}: {error}

What it means

The URL's host could not be parsed into a grantable HostPattern for a reason other than being an IP literal: the pattern parser rejected the host string itself (invalid characters, malformed labels). Because network access cannot be authorized, the fetch fails before connecting; the message includes the parser's error.

Source

Thrown at crates/agent/src/tools/fetch_tool.rs:210

}

/// Extracts the host from a fetch URL as a [`http_proxy::HostPattern`] so it can
/// be matched against the shared network grants. Mirrors the scheme handling in
/// [`normalize_url`] (defaulting to `https://` when none is given).
fn host_pattern_for_url(url: &str) -> Result<http_proxy::HostPattern> {
    let normalized = normalize_url(url);
    let parsed =
        url::Url::parse(&normalized).with_context(|| format!("could not parse URL {url:?}"))?;
    let host = parsed
        .host_str()
        .with_context(|| format!("URL {url:?} has no host to authorize network access for"))?;
    http_proxy::HostPattern::parse(host).map_err(|error| match error {
        http_proxy::HostPatternError::IpLiteral(_) => anyhow::anyhow!(
            "cannot fetch {host:?}: loopback and IP-literal hosts can't be granted network \
             access individually. They are only reachable once unsandboxed access has been \
             granted (for example, via a terminal command that requests it)."
        ),
        error => anyhow::anyhow!("cannot authorize network access to {host:?}: {error}"),
    })
}

impl AgentTool for FetchTool {
    type Input = FetchToolInput;
    type Output = String;

    const NAME: &'static str = "fetch";

    fn kind() -> acp::ToolKind {
        acp::ToolKind::Fetch
    }

    fn allow_in_restricted_mode() -> bool {
        false
    }

    fn initial_title(

View on GitHub (pinned to bc538def45)

Solutions

1. Correct the host: remove glob metacharacters and stray characters from the hostname.
2. Pre-validate the URL with `url::Url::parse` before handing it to the fetch tool.
3. If an underscore host is genuinely required, expose the service under a valid DNS name instead.

Example fix

# before
fetch http://api_.example.com/x     # '_' rejected by HostPattern::parse
fetch http://*.example.com/x       # glob metacharacter in host

# after
fetch http://api.example.com/x

let host = url::Url::parse(&normalize_url(url))?
    .host_str()
    .ok_or_else(|| anyhow::anyhow!("URL {url:?} has no host"))?
    .to_string();
// Fail early with the parser's own error instead of mid-fetch.
http_proxy::HostPattern::parse(&host)?;

fn is_grantable_host(host: &str) -> bool {
    !host.is_empty()
        && !host.chars().any(|c| matches!(c, '*' | '?' | '[' | ']'))
        && http_proxy::HostPattern::parse(host).is_ok()
}

When it happens

Trigger: URLs whose host contains characters invalid for host patterns — glob metacharacters like '*', '?', '[', ']' — or empty/malformed hosts surviving URL normalization.

Common situations: Model-generated URLs with glob-like or regex-like hosts; hostnames with underscores (invalid in DNS but present in some internal systems); copy-paste artifacts introducing stray characters.

Related errors

• cannot fetch {host:?}: loopback and IP-literal hosts can't b
• unknown benchmark '{benchmark_id}' (valid: {valid})
• unknown benchmark '{selector}' (valid: {valid})
• build ids may only contain lowercase letters, numbers, '.',
• unknown judge preset '{name}' (valid: {valid})

AI-assisted analysis of zed-industries/zed@bc538def45 (2026-08-16). Data as JSON: /api/errors/2848f6d58926f5d3. Report an issue: GitHub.