Copilot cloud agent OIDC token no longer includes environment in subject claim, breaking Azure federated credential login (regression since ~May 5-9, 2026)

[avrum]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

Copilot in GitHub

Body

Copilot cloud agent OIDC token no longer includes environment in subject claim, breaking Azure federated credential login (regression ~May 2026)

Summary

The Copilot cloud agent's dynamic workflow (/dynamic/copilot-swe-agent/copilot@...) stopped including the GitHub Actions environment in the OIDC token's sub claim around early May 2026. This completely breaks Azure OIDC federated credential login for any setup using the environment:copilot subject pattern, which is the officially documented and recommended configuration per:

• Microsoft's azd coding-agent config extension ([blog post](https://devblogs.microsoft.com/azure-sdk/azure-developer-cli-copilot-coding-agent-config/))
• GitHub's Enterprise Cloud docs for Copilot + Azure MCP (docs)
• Microsoft's quickstart for Copilot coding agent Azure access ([docs](https://learn.microsoft.com/en-us/azure/developer/azure-developer-cli/extensions/copilot-coding-agent-extension))

The Problem

When environment: copilot is set on the copilot-setup-steps job, the OIDC token's subject claim should be:

repo:<my-org>/<my-repo>:environment:copilot

Instead, since approximately May 5-9, 2026, the dynamic workflow emits:

repo:<my-org>/<my-repo>:ref:refs/heads/copilot/<branch-name>

This causes Azure to reject the token with AADSTS700213: No matching federated identity record found.

Evidence: Before and After

Same workflow file, same repository, same Azure federated credential, same managed identity. Nothing changed on our side.

SUCCESSFUL run (early May 2026):

Secret source: None
subject claim - repo:<my-org>/<my-repo>:environment:copilot              ✅ CORRECT
job_workflow_ref - /dynamic/copilot-swe-agent/copilot@refs/heads/copilot/<branch-name>
Azure CLI login succeeds by using OIDC.

FAILED run (~4 days later):

Secret source: AgentSecrets                                               ⚠️ CHANGED
subject claim - repo:<my-org>/<my-repo>:ref:refs/heads/copilot/<branch-name>    ❌ WRONG
job_workflow_ref - /dynamic/copilot-swe-agent/copilot@refs/heads/copilot/<branch-name>
Error: AADSTS700213: No matching federated identity record found

Key differences:

1. Secret source changed from None to AgentSecrets
2. OIDC subject changed from environment:copilot to ref:refs/heads/copilot/...

Self-Service Fix Attempted: OIDC Subject Claim Customization

I tried to fix this using the repository-level OIDC Configuration page (Settings > Actions > OIDC):

1. Unchecked "Use default template"
2. Set the Subject claim template to: repo, context
3. Saved successfully
4. Triggered a new Copilot cloud agent session

Result: The dynamic workflow completely ignored the custom template. The subject claim still showed ref:refs/heads/copilot/.... The context variable should resolve to the environment name when the job specifies environment: copilot (per [GitHub's OIDC docs](https://docs.github.com/en/actions/reference/security/oidc)), but the Copilot agent's dynamic workflow bypasses the repository-level OIDC subject claim customization entirely.

Our Configuration (matches all official docs)

copilot-setup-steps.yml:

on:
  workflow_dispatch:
permissions:
  id-token: write
  contents: read
jobs:
  copilot-setup-steps:
    runs-on: ubuntu-latest
    permissions:
      id-token: write
      contents: read
    environment: copilot
    steps:
      - name: Azure login
        continue-on-error: true
        uses: azure/login@v3
        with:
          client-id: ${{ vars.AZURE_CLIENT_ID }}
          tenant-id: ${{ vars.AZURE_TENANT_ID }}
          subscription-id: ${{ vars.AZURE_SUBSCRIPTION_ID }}

Azure Federated Credential (User-Assigned Managed Identity):

Issuer:   https://token.actions.githubusercontent.com
Subject:  repo:<my-org>/<my-repo>:environment:copilot
Audience: api://AzureADTokenExchange

This is exactly what Microsoft's azd coding-agent config generates automatically.

Three Things the Dynamic Workflow Ignores

1. environment: copilot on the copilot-setup-steps job (for OIDC subject generation)
2. Repository-level OIDC Subject claim template customization (Settings > Actions > OIDC)
3. The documented behavior where context resolves to the environment name per [GitHub's OIDC reference](https://docs.github.com/en/actions/reference/security/oidc)

Why There Is No Azure-Side Workaround

• Azure federated identity credentials on managed identities require exact subject matching
• Wildcards are not supported in the subject field ([Microsoft docs](https://learn.microsoft.com/en-us/entra/workload-id/workload-identity-federation-considerations))
• Azure's "Flexible federated identity credentials" (preview) which support wildcard matching via claimsMatchingExpression are only available on App Registrations, not managed identities ([Microsoft docs](https://learn.microsoft.com/en-us/entra/workload-id/workload-identities-flexible-federated-identity-credentials))
• The environment:copilot pattern IS the recommended solution for dynamic branch names, because it is branch-agnostic. That is specifically why Microsoft's tooling generates it.

Impact

• Azure OIDC login is completely broken for all Copilot cloud agent sessions
• The agent cannot access Azure resources (Application Insights, Key Vault, Cosmos DB, etc.) via the Azure MCP Server
• The only workaround is continue-on-error: true on the Azure login step, which means the agent runs without Azure access
• This defeats the purpose of the Azure MCP Server integration with Copilot

Expected Behavior

The OIDC token's sub claim should be repo:<org>/<repo>:environment:copilot when the copilot-setup-steps job specifies environment: copilot, regardless of which copilot/* branch the dynamic workflow runs on. This was the correct behavior prior to early May 2026.

Is Anyone Else Hitting This?

If you are using Copilot cloud agent with Azure OIDC login (via azure/login with federated credentials on a managed identity), and your login started failing around early May 2026, you are likely hitting the same issue. Check your Action logs for whether the subject claim shows environment:copilot or ref:refs/heads/copilot/....

I have also filed a support ticket with GitHub for this issue.

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[avrum]

Any feedback about this issue?

[asaddevx]

Hey @avrum,

Thanks for the incredibly detailed report. I've looked into this and unfortunately, it seems you've hit a genuine bug.

Based on your thorough analysis, the issue is clear. Since around May 5th, the Copilot cloud agent's dynamic workflow has stopped including the GitHub Actions environment in the OIDC token's sub claim. Instead of the expected environment:copilot, it's sending ref:refs/heads/copilot/.... This is a regression, as this behavior was working correctly before.

Because Azure's federated identity credentials require an exact match on the sub claim, there is no way for you to fix this from your side. Your attempts to customize the OIDC subject claim in your repository settings were ignored, as the dynamic workflow seems to bypass them.

For now, there is no workaround. However, here's the best path forward:

1. Upvote the issue: The more upvotes this gets, the more attention it will receive from GitHub.
2. Share your specific use case: As you've already done, mentioning that this breaks the official Microsoft azd workflow adds valuable context.
3. Watch this space: Your best hope is for GitHub to revert this change in a future update.

You've already opened a ticket with GitHub Support, which is the right move. The ball is now in their court to fix this regression.

Thank you for being so persistent.

[avrum]

Anyone has similar issues?

[NilsWmn]

Yes. Let us know if you found any fix for it.

[avrum]

I can't belive that there the docs still stating that this is the best practice while it's just broke in the last few weeks without any notice

[jamie-nzfunds]

We're experiencing the same issue with setting up integration between Azure & Github Copilot. It's been a big waste of time so far.

[avrum]

Seems like we all have this same issue, would you mind also create a ticket for GitHub?
I created 2 already wihtout any response.

[avrum]

If anyone else experience this issue, please upvote to get some trackion for this critical issue,
And if you have any workarround please note as well, thanks!

[johnwc]

We see it as well. You need to create a support ticket for it though instead of a discussion.
https://support.github.com/tickets/

[avrum]

Already did... but didn't get any response...

[justinmchase]

We are also experiencing this issue, confirmed. It was working for us before this date and suddenly stopped working.

[avrum]

Seems like we all have this same issue, would you mind also create a ticket for GitHub?
I created 2 already wihtout any response.

[avrum]

Any one got any response? or a workarround?

[johnwc]

Response from support

Hi John,

We have an internal issue for this. And the dev team have a pending PR for the dix. As soon as we get conifirmation it's been released, I will follow up.

[avrum]

Thanks, any tips to get reponse from GitHub tickets>
I have 3 open ticket for over 3 weeks without any response