[BUG] Cowork/Claude Code egress proxy blocks dev.azure.com with 403 despite domain present in Capabilities network allowlist

Status Fixed / completed
Maintainer reply None cached
Activity 1 comment · opened Sep 11, 2026 · closed Sep 12, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

Description:

dev.azure.com is present in my organization's network egress allowlist (Admin Settings → Capabilities → Network Access), and API calls to it worked successfully in this same Cowork session yesterday (2026-09-10). Starting today (2026-09-11), every request to dev.azure.com:443 is rejected at the CONNECT stage by the session's egress proxy with a 403, before any application-level request or credential is even sent.

Similarly:
management.azure.com: connect_rejected — gateway answered 403 to CONNECT (policy denial or upstream failure)
login.microsoftonline.com: connect_rejected — gateway answered 403 to CONNECT (policy denial or upstream failure)

also

Proxy status output confirms the rejection is a policy-level denial, not a certificate or connectivity failure:

"recentRelayFailures": [
  {"ts": "2026-09-11T08:56:12.843Z", "kind": "connect_rejected",
   "detail": "gateway answered 403 to CONNECT (policy denial or upstream failure)",
   "host": "dev.azure.com:443"}
]

No change was made to my org's allowlist between yesterday and today, and no active incident for this is listed on status.claude.com as of this report.

Impact: blocks all Azure DevOps REST API access (work item tracking, PR review, backlog management) from this Cowork session — a daily-use dependency for this project.

What Should Happen?

These same hosts, from this same session type, succeeded without issue on 2026-09-10 — I authenticated to Azure AD via login.microsoftonline.com (OAuth2 client-credentials flow) and made read-only ARM calls to management.azure.com for a resource group under subscription b021b2f4-38e2-4a54-b037-222c8fd35f5a. As of 2026-09-11, the identical calls, same credentials, same subscription, fail at the proxy level with no change on my end. Nothing in this session's own configuration changed between the two days — the proxy's noProxy/allowlist configuration is otherwise unchanged and neither host is deliberately blocklisted in anything visible to me.

Expected behavior: management.azure.com and login.microsoftonline.com should be reachable from this session's egress proxy the same way they were on the 10th, so I can resume pulling live Azure Resource Manager state for this project directly, rather than routing every check through a teammate's own session.

Error Messages/Logs

"recentRelayFailures": [
  {"ts": "2026-09-11T08:56:12.843Z", "kind": "connect_rejected",
   "detail": "gateway answered 403 to CONNECT (policy denial or upstream failure)",
   "host": "dev.azure.com:443"}
]

Steps to Reproduce

In Claude Desktop, Settings, Capabilities, Domain Allowlist includes

  • dev.azure.com
  • graph.microsoft.com
  • login.microsoftonline.com
  • management.azure.com
  • prices.azure.com

Prompt the Cowork or Chat agent to submit an update to work item in DevOps Boards (located in dev.azure.com)

Note that operations such as this were working fine yesterday.

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

Desktop version 1.52386.0

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

_No response_

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗