Agent denied network access via curl to explicitly allowed domains; sometimes gives up entirely

[wtgodbe]

Agent denied network access via curl to explicitly allowed domains; sometimes gives up entirely

Summary

Our agentic workflow's agent is consistently denied network access when using curl to reach domains explicitly listed in --allow-domains. The error is "Permission denied and could not request permission from user" — suggesting the Copilot CLI is trying to interactively prompt for approval rather than running autonomously. curl is also explicitly in the --allow-tool list (shell(curl)).

This is a problem in two ways:

1. curl never works despite the target domains being in --allow-domains and curl being in --allow-tool. This appears to be a bug — python3's urllib.request can reach the same domains successfully, so the network firewall itself allows the traffic. Something specific to curl invocations is being blocked by the permission system.

2. The agent sometimes gives up entirely instead of trying an alternate approach. In the working run, the agent recovered by falling back to python3 after curl was denied. In the broken run, the agent gave up after the first curl denial. This is non-deterministic agent behavior, but the underlying issue is that curl shouldn't be denied in the first place.

Reproduction

Working run (curl denied, agent falls back to python3): https://github.com/dotnet/aspnetcore/actions/runs/23976785846/job/69935014329
Broken run (curl denied, agent gives up): https://github.com/dotnet/aspnetcore/actions/runs/24028303564/job/70071528101

Both runs use identical --allow-domains lists, identical --allow-tool lists (including shell(curl)), and identical Copilot CLI flags.

Workflow definition: https://github.com/dotnet/aspnetcore/blob/main/.github/workflows/test-quarantine.md

Details

The workflow needs to reach dev.azure.com, vstmr.dev.azure.com, and helix.dot.net to fetch build and test data. All three are in the --allow-domains list. curl is in the --allow-tool list as shell(curl).

Working run — curl denied 3 times, agent falls back to python3 which works:

✗ Get builds for pipeline 84 (quarantined tests) (shell)
  │ curl -s "https://dev.azure.com/dnceng-public/public/_apis/build/builds?..." | python3 -c "..."
  └ Permission denied and could not request permission from user

● Test AzDO API access via python (shell)
  │ python3 -c "import urllib.request, json; url = 'https://dev.azure.com/...'; ..."
  └ 59 lines...    ← success, agent continues working

Broken run — curl denied once, agent gives up entirely:

✗ Test AzDO API access (shell)
  │ curl -s --max-time 30 "https://dev.azure.com/dnceng-public/public/_apis/build/builds?..."
  └ Permission denied and could not request permission from user

Network access to Azure DevOps and Helix APIs is blocked by the sandbox firewall.

Expected behavior

• curl to domains in --allow-domains should work without prompting for user approval. The agent runs non-interactively in an agentic workflow — there is no user to approve anything.
• At minimum, the permission system should not distinguish between curl and python3's urllib.request when both are allowed tools accessing allowed domains.

Possible contributing factor

The working run used AWF image 0.25.11 while the broken run used 0.25.13. This may be coincidental (the curl denial appears in both versions), but noting it in case the image upgrade affected agent behavior around retries/fallbacks.

Environment

• Workflow: dotnet/aspnetcore daily test quarantine management (workflow definition)
• All flags (allowed tools, allowed paths, allowed domains, copilot CLI args) are identical between runs