Any tunnel that historically lived in the euw cluster now comes back in a different cluster when recreated after expiry: devtunnel create against the euw relay returns exit code 0 with the tunnel placed in eun1. The public URL encodes the cluster, so everything registered against the old URL — OAuth redirect URIs, webhooks, bot channel endpoints — breaks, and automation has nothing to catch: the create reports success.
We hit this naturally today: an expired dev tunnel that had lived in euw for months was recreated by our setup tooling and came back on eun1, breaking the OIDC redirect URIs registered against its euw URL.
Repro
Reproduces on every attempt (2026-07-13, CLI 1.0.1824 and 1.0.1972, Microsoft org identity):
$ devtunnel create pin-repro --service-uri https://euw.rel.tunnels.api.visualstudio.com
Tunnel ID : pin-repro.eun1 # requested euw, created in eun1, exit code 0
Controls — every other cluster we tried honours the target, so this is euw-specific placement, not a broken flag:
$ devtunnel create pin-repro-2 --service-uri https://use.rel.tunnels.api.visualstudio.com
Tunnel ID : pin-repro-2.use # ✓
$ devtunnel create pin-repro-3 --service-uri https://uks1.rel.tunnels.api.visualstudio.com
Tunnel ID : pin-repro-3.uks1 # ✓
$ devtunnel create pin-repro-4 --service-uri https://bogus.example.invalid
Name or service not known (bogus.example.invalid:443) # the URI is dialed, not ignored
devtunnel clusters still lists euw (WestEurope) and pings it fastest from here (29 ms). Existing euw tunnels keep hosting fine — only new creates relocate. Unpinned creates land in the nearest other cluster (uks1), so recreation changes the URL for previously-euw tunnels regardless of whether --service-uri is used.
Likely cause
#643 was closed with: "some clusters will be dedicated to first-party services and will no longer be accessible to end users… The CLI will be augmented to use the recommended cluster by default." If euw has crossed that line, this is presumably that policy taking effect — but nothing in the create flow surfaces it. (Related: #642 — the same silent-cross-cluster class of failure.)
This doesn't only affect scripts: Aspire's DevTunnels integration pins the cluster the same way (DevTunnelOptions.Region → --service-uri, microsoft/aspire#14112) and then addresses the tunnel by {id}.{regionCode} — a create relocated to another cluster makes every subsequent command miss.
Ask
When a create is placed in a different cluster than the relay it targeted, fail the create — or at minimum print a warning and return a nonzero exit — so tooling that depends on cluster-stable URLs can react instead of discovering the move when sign-in breaks.
Investigated and drafted with AI assistance (Claude Code); repro steps were run and outputs captured verbatim.
Any tunnel that historically lived in the
euwcluster now comes back in a different cluster when recreated after expiry:devtunnel createagainst the euw relay returns exit code 0 with the tunnel placed ineun1. The public URL encodes the cluster, so everything registered against the old URL — OAuth redirect URIs, webhooks, bot channel endpoints — breaks, and automation has nothing to catch: the create reports success.We hit this naturally today: an expired dev tunnel that had lived in euw for months was recreated by our setup tooling and came back on
eun1, breaking the OIDC redirect URIs registered against its euw URL.Repro
Reproduces on every attempt (2026-07-13, CLI 1.0.1824 and 1.0.1972, Microsoft org identity):
Controls — every other cluster we tried honours the target, so this is euw-specific placement, not a broken flag:
devtunnel clustersstill lists euw (WestEurope) and pings it fastest from here (29 ms). Existing euw tunnels keep hosting fine — only new creates relocate. Unpinned creates land in the nearest other cluster (uks1), so recreation changes the URL for previously-euw tunnels regardless of whether--service-uriis used.Likely cause
#643 was closed with: "some clusters will be dedicated to first-party services and will no longer be accessible to end users… The CLI will be augmented to use the recommended cluster by default." If euw has crossed that line, this is presumably that policy taking effect — but nothing in the create flow surfaces it. (Related: #642 — the same silent-cross-cluster class of failure.)
This doesn't only affect scripts: Aspire's DevTunnels integration pins the cluster the same way (
DevTunnelOptions.Region→--service-uri, microsoft/aspire#14112) and then addresses the tunnel by{id}.{regionCode}— a create relocated to another cluster makes every subsequent command miss.Ask
When a create is placed in a different cluster than the relay it targeted, fail the create — or at minimum print a warning and return a nonzero exit — so tooling that depends on cluster-stable URLs can react instead of discovering the move when sign-in breaks.
Investigated and drafted with AI assistance (Claude Code); repro steps were run and outputs captured verbatim.