Provider-based authentication for Claude, Copilot, Codex.

[dsyme]

1. Our docs barely mention "CLAUDE_CODE_OAUTH_TOKEN" but it seems it is, in some sense, supported. But it's unclear how - the line

		"CLAUDE_CODE_OAUTH_TOKEN": "${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }}",

seems to indicate that the CLAUDE_CODE_OAUTH_TOKEN should be stored as a secret but that should really be documented more

2. We need to consider provider-based auth for Claude and Codex and Copilot. The claude provider-based authetication is here: https://code.claude.com/docs/en/authentication#cloud-provider-authentication

If we do we will also need to reconsider a few things in gh aw secrets bootstrap and gh aw add-wizard and so on. For example, if we add a workflow that is clearly using provider-based authentication then we really don't need any secret at all for that particular workflow - but may need an APP_ID or similar.

[mstrathman]

AWF API proxy doesn't support OAuth authentication

We've been using CLAUDE_CODE_OAUTH_TOKEN with gh-aw on self-hosted ARM64 runners to bill through our Claude Teams subscription instead of per-token API usage. This was working previously but broke in a recent update.

The AWF agent sandbox's API proxy currently only supports ANTHROPIC_API_KEY. When CLAUDE_CODE_OAUTH_TOKEN is set, Claude Code may use a different API endpoint or auth flow entirely, not just a different header on api.anthropic.com. The proxy strips client auth headers and injects x-api-key, and the Squid domain whitelist may block whatever endpoint OAuth needs to reach.

Today the only workaround is sandbox: agent: false (+ strict: false) to bypass the proxy entirely, which defeats the purpose of the sandbox and introduces secondary issues (no privilege drop, root-user conflicts with --permission-mode bypassPermissions).

Ask: Support CLAUDE_CODE_OAUTH_TOKEN as an alternative auth method through the sandbox. We're not sure what's involved, whether OAuth uses the same Anthropic API endpoint with a different header or a completely different backend, but either way it would be great to understand what's needed and get it on the roadmap.

Environment: self-hosted ARM64 Linux runners, Ubuntu 22.04 LXC containers, gh aw v0.47.3.

[pelikhan]

It is not supported.

[mstrathman]

It is not supported.

Understood. +1 for supporting it when priorities allow.

[dsyme]

@mstrathman Just to check - one reason we haven't been supporting CLAUDE_CODE_OAUTH_TOKEN is because we had the impression Anthropic were locking down on the use of this - transferring one token from one tool to another tool.

But I want to just check - what's the technique you're using to get CLAUDE_CODE_OAUTH_TOKEN - is it one of the legitimate automated OIDC techniques for authentication?

If so we should revisit and support this.

[mstrathman]

Hey, @dsyme, yeah, it is my understanding that Anthropic has been locking down abuse of CLAUDE_CODE_OAUTH_TOKENs, wondering if you think these would still be valid uses:

For shared repos, an OIDC makes sense there to differentiate which user is initiating tasks rather than everything running under a shared identity.

For solo developer repos, OIDC isn't really the point. It's simpler than that: a single developer working in their own repository. The token already represents them, there's no handoff between tools or identities happening, just their credentials running in a different execution context than their local machine.

Totally understand if this use case it's not a priority.