[Bug]: AWS_PROFILE using credential_process is rejected ("credentials provider was not properly configured")

[byongwu]

Bug Description

When configuring the Bedrock provider via forge provider login bedrock, entering a profile name that uses credential_process in ~/.aws/config fails with:

ERROR: Authentication completion failed: Failed to resolve credentials for profile 'SMUS2': the credentials provider was not properly configured. Try running 'aws sso login --profile SMUS2'

The profile itself is valid — aws sts get-caller-identity --profile SMUS2 returns credentials without error, and other agentic CLIs (e.g., Claude Code, which is what I currently use day-to-day) pick up the same profile with no issue. ForgeCode appears to only accept SSO or static credentials, not profiles that resolve credentials via the standard AWS SDK credential_process chain.

Related: #2830 (closed as "Support SSO for AWS Bedrock"). That change added SSO support, but credential_process — which is an equally standard AWS SDK mechanism — is still not handled.

Steps to Reproduce

1. Configure an AWS profile that uses credential_process (this is the AWS-recommended pattern for environments where long-lived IAM access keys are disallowed and credentials are brokered by an internal/enterprise tool):

   # ~/.aws/config
   [profile SMUS2]
   credential_process = <internal-corporate-tool> credentials --awscli <account> --role Admin

2. Confirm the profile resolves correctly via the AWS SDK:

   $ aws sts get-caller-identity --profile SMUS2
   {
     "UserId": "...",
     "Account": "...",
     "Arn": "arn:aws:sts::...:assumed-role/Admin/..."
   }
   

3. Run forge provider login bedrock:

   ? Enter AWS_REGION: us-east-1
   ? Enter AWS_PROFILE: SMUS2
   ● ERROR: Authentication completion failed: Failed to resolve credentials for profile 'SMUS2': ...
   

Expected Behavior

ForgeCode should resolve credentials using the standard AWS SDK credential provider chain. That chain natively supports credential_process alongside SSO and static credentials — nothing extra is required if the default chain is used. The same profile works transparently in the AWS CLI, boto3, and other AI coding CLIs (e.g., Claude Code).

Additionally, it would be great if ForgeCode could fall back to the default credential chain when no profile is specified, rather than always prompting for AWS_PROFILE. In my setup Claude Code is configured with no explicit profile and just picks up whatever the shell's AWS_DEFAULT_PROFILE / default chain resolves to. Requiring a profile name up-front is friction for users who already have AWS_DEFAULT_PROFILE / AWS_PROFILE exported or who just want the SDK default.

Actual Behavior

ForgeCode rejects credential_process profiles with a message suggesting aws sso login, which is misleading — the profile is not SSO, and running aws sso login against it produces:

Missing the following required SSO configuration values: sso_start_url, sso_region.

Workaround currently in use: run the internal credential tool with --update to write STS temp credentials into ~/.aws/credentials as static aws_access_key_id / aws_secret_access_key / aws_session_token. This works but has ~1h TTL and has to be refreshed manually before each session — operationally brittle.

Forge Version

forge 2.12.12

Operating System & Version

macOS darwin 25.3.0

AI Provider

Amazon Bedrock

Installation Method

curl -fsSL https://forgecode.dev/cli | sh

Impact

Enterprise environments where long-lived IAM access keys are prohibited commonly broker short-lived credentials through a wrapper tool and expose them via credential_process. This is the AWS-recommended pattern for such organizations, and it is supported out of the box by the AWS SDKs (botocore, aws-sdk-js v3, aws-sdk-go v2, etc.). Public tools like aws-vault, awsume, and Granted all emit credential_process-style profiles as their primary integration point. Without support for it, ForgeCode effectively cannot be used in these organizations against Bedrock.