Background
Anthropic GA'd Claude Platform on AWS on 2026-05-11:
It's a fifth auth/transport surface alongside the four this action currently supports (direct Anthropic, Bedrock, Vertex, Foundry). Anthropic's official SDKs ship first-class support (from anthropic import AnthropicAWS in Python and equivalents in TS / Go / Java / C# / PHP / Ruby), and the Claude Code CLI itself reads ANTHROPIC_AWS_WORKSPACE_ID and ANTHROPIC_AWS_BASE_URL env vars natively.
Current state
action.yml exposes use_bedrock, use_vertex, use_foundry and forwards the relevant env vars (CLAUDE_CODE_USE_BEDROCK, AWS_REGION, ANTHROPIC_VERTEX_PROJECT_ID, ANTHROPIC_FOUNDRY_BASE_URL, etc.) but no use_aws_platform flag and no ANTHROPIC_AWS_WORKSPACE_ID / ANTHROPIC_AWS_BASE_URL passthrough. docs/cloud-providers.md documents the four existing providers and doesn't reference Platform on AWS.
This means: setting only ANTHROPIC_AWS_WORKSPACE_ID on a step and omitting anthropic_api_key triggers the action's validation error ("must provide one of: api_key, use_bedrock, use_vertex, use_foundry"). There's no path through the action today.
Proposed
Add the fifth provider in parallel to the existing four:
- New input:
use_aws_platform: \"true\" (or whatever naming matches the public-facing name)
- Forward to the wrapped Claude Code CLI:
ANTHROPIC_AWS_WORKSPACE_ID (from ${{ env.ANTHROPIC_AWS_WORKSPACE_ID }} — required when use_aws_platform is true)ANTHROPIC_AWS_BASE_URL (optional; SDK defaults to https://gateway.{region}.api.aws from AWS_REGION)ANTHROPIC_AWS_API_KEY (optional; SDK falls back to SigV4 via the AWS credential chain if absent)
- Reuse the existing OIDC pattern (
aws-actions/configure-aws-credentials@v4) for credential supply
- Add a section to
docs/cloud-providers.md matching the Bedrock/Vertex/Foundry templates
Concrete use case
Mid-size org with ~$1k+/month CI Claude spend wants to consolidate dev-side spend onto AWS commits via Platform-on-AWS. Direct Anthropic CI workflows (UX reviewer in our case) are the lowest-risk migration target — but the action's lack of a use_aws_platform flag blocks them today.
Happy to test a draft end-to-end against our PR reviewer workflow.
Background
Anthropic GA'd Claude Platform on AWS on 2026-05-11:
It's a fifth auth/transport surface alongside the four this action currently supports (direct Anthropic, Bedrock, Vertex, Foundry). Anthropic's official SDKs ship first-class support (
from anthropic import AnthropicAWSin Python and equivalents in TS / Go / Java / C# / PHP / Ruby), and the Claude Code CLI itself readsANTHROPIC_AWS_WORKSPACE_IDandANTHROPIC_AWS_BASE_URLenv vars natively.Current state
action.ymlexposesuse_bedrock,use_vertex,use_foundryand forwards the relevant env vars (CLAUDE_CODE_USE_BEDROCK,AWS_REGION,ANTHROPIC_VERTEX_PROJECT_ID,ANTHROPIC_FOUNDRY_BASE_URL, etc.) but nouse_aws_platformflag and noANTHROPIC_AWS_WORKSPACE_ID/ANTHROPIC_AWS_BASE_URLpassthrough.docs/cloud-providers.mddocuments the four existing providers and doesn't reference Platform on AWS.This means: setting only
ANTHROPIC_AWS_WORKSPACE_IDon a step and omittinganthropic_api_keytriggers the action's validation error ("must provide one of: api_key, use_bedrock, use_vertex, use_foundry"). There's no path through the action today.Proposed
Add the fifth provider in parallel to the existing four:
use_aws_platform: \"true\"(or whatever naming matches the public-facing name)ANTHROPIC_AWS_WORKSPACE_ID(from ${{ env.ANTHROPIC_AWS_WORKSPACE_ID }} — required when use_aws_platform is true)ANTHROPIC_AWS_BASE_URL(optional; SDK defaults tohttps://gateway.{region}.api.awsfromAWS_REGION)ANTHROPIC_AWS_API_KEY(optional; SDK falls back to SigV4 via the AWS credential chain if absent)aws-actions/configure-aws-credentials@v4) for credential supplydocs/cloud-providers.mdmatching the Bedrock/Vertex/Foundry templatesConcrete use case
Mid-size org with ~$1k+/month CI Claude spend wants to consolidate dev-side spend onto AWS commits via Platform-on-AWS. Direct Anthropic CI workflows (UX reviewer in our case) are the lowest-risk migration target — but the action's lack of a
use_aws_platformflag blocks them today.Happy to test a draft end-to-end against our PR reviewer workflow.