anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-22 02:05:26 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

Bedrock provider fails to use credential chain even when explicitly set in config #8987

New Issue
Closed
opened 2026-02-16 18:11:19 -05:00 by yindo · 1 comment
yindo commented 2026-02-16 18:11:19 -05:00
Owner
Copy Link
Copy Source

Originally created by @crw2998 on GitHub (Feb 10, 2026).

Originally assigned to: @rekram1-node on GitHub.

Description

Even when explicitly specified as a provider in opencode.json, the Bedrock provider doesn't work unless AWS_ACCESS_KEY_ID etc are set. This means the native credential chain doesn't work when running opencode serve on Lambda, ECS, etc.

Environment

  • opencode version: 1.1.53

  • Runtime: ECS Fargate

  • Relevant env vars:

    • AWS_EXECUTION_ENV=AWS_ECS_FARGATE
    • AWS_CONTAINER_CREDENTIALS_RELATIVE_URI=/v2/credentials/<redacted>
    • AWS_REGION=us-east-1
    • AWS_DEFAULT_REGION=us-east-1

  • Not set:

    • AWS_ACCESS_KEY_ID
    • AWS_SECRET_ACCESS_KEY
    • AWS_SESSION_TOKEN
    • AWS_PROFILE
    • AWS_WEB_IDENTITY_TOKEN_FILE
    • AWS_BEARER_TOKEN_BEDROCK

Config

opencode.json includes Bedrock provider:

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "amazon-bedrock": {
      "options": {
        "region": "us-east-1"
      }
    }
  }
}

Observed behavior

$ env -u AWS_ACCESS_KEY_ID -u AWS_SECRET_ACCESS_KEY -u AWS_SESSION_TOKEN \
    -u AWS_PROFILE -u AWS_BEARER_TOKEN_BEDROCK -u AWS_WEB_IDENTITY_TOKEN_FILE \
    OPENCODE_CONFIG="/path/to/opencode.json" \
    opencode run -m "amazon-bedrock/anthropic.claude-opus-4-6-v1" "ping"
Error: AWS SigV4 authentication requires AWS credentials...
Original error: AWS access key ID setting is missing...

Command that should work when static creds are set
(uses the normal AWS env vars; in ECS/Fargate these are typically injected automatically)

$ OPENCODE_CONFIG="/path/to/opencode.json" \
  opencode run -m "amazon-bedrock/anthropic.claude-opus-4-6-v1" "ping"

Expected

If amazon-bedrock is specified as a provider and AWS_CONTAINER_CREDENTIALS_RELATIVE_URI is set, Bedrock should authenticate via the AWS SDK credential chain without needing to inject AWS_ACCESS_KEY_ID directly.

The following analysis is from Codex:

Additional verification

  • opencode models lists Bedrock models even when only the container credential URI is present:
env -u AWS_PROFILE -u AWS_ACCESS_KEY_ID -u AWS_WEB_IDENTITY_TOKEN_FILE -u AWS_BEARER_TOKEN_BEDROCK \
    -u AWS_CONTAINER_CREDENTIALS_FULL_URI -u AWS_CONTAINER_CREDENTIALS_RELATIVE_URI \
    OPENCODE_CONFIG="/path/to/opencode.json" opencode models
  • opencode run succeeds when standard AWS env creds are set (same config):
OPENCODE_CONFIG="/path/to/opencode.json" opencode run -m "amazon-bedrock/anthropic.claude-opus-4-6-v1" "ping"

Likely root cause

In packages/opencode/src/provider/provider.ts, the Bedrock loader only autoloads if one of:

  • AWS_PROFILE
  • AWS_ACCESS_KEY_ID
  • AWS_BEARER_TOKEN_BEDROCK
  • AWS_WEB_IDENTITY_TOKEN_FILE
    is present. It does not consider AWS_CONTAINER_CREDENTIALS_{RELATIVE,FULL}_URI, so the loader never wires the SDK credential chain in environments that rely on the container credentials endpoint. Even though the provider appears in config, the loader doesn’t initialize because autoload is gated on env hints.

Fix needed

The Bedrock provider should initialize when it is explicitly configured in opencode.json, even if no env-based credential hints are present. That should be sufficient to trigger fromNodeProviderChain(...) so the AWS SDK can discover container credentials.
Additionally (or as a fallback), treat AWS_CONTAINER_CREDENTIALS_RELATIVE_URI or AWS_CONTAINER_CREDENTIALS_FULL_URI as a valid autoload signal.

Plugins

None

OpenCode version

1.1.53

Steps to reproduce

Run opencode run -m "amazon-bedrock/anthropic.claude-opus-4-6-v1 in the description with AWS_CONTAINER_CREDENTIALS_RELATIVE_URI specified, but without AWS_ACCESS_KEY_ID, etc, and using the following config:

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "amazon-bedrock": {
      "options": {
        "region": "us-east-1"
      }
    }
  }
}

Screenshot and/or share link

No response

Operating System

Linux -- Debian 12 (Bookworm)

Terminal

No response

Originally created by @crw2998 on GitHub (Feb 10, 2026). Originally assigned to: @rekram1-node on GitHub. ### Description Even when explicitly specified as a provider in opencode.json, the Bedrock provider doesn't work unless AWS_ACCESS_KEY_ID etc are set. This means the native credential chain doesn't work when running `opencode serve` on Lambda, ECS, etc. ### Environment - opencode version: 1.1.53 - Runtime: ECS Fargate - Relevant env vars: - `AWS_EXECUTION_ENV=AWS_ECS_FARGATE` - `AWS_CONTAINER_CREDENTIALS_RELATIVE_URI=/v2/credentials/<redacted>` - `AWS_REGION=us-east-1` - `AWS_DEFAULT_REGION=us-east-1` - Not set: - `AWS_ACCESS_KEY_ID` - `AWS_SECRET_ACCESS_KEY` - `AWS_SESSION_TOKEN` - `AWS_PROFILE` - `AWS_WEB_IDENTITY_TOKEN_FILE` - `AWS_BEARER_TOKEN_BEDROCK` ### Config opencode.json includes Bedrock provider: ``` { "$schema": "https://opencode.ai/config.json", "provider": { "amazon-bedrock": { "options": { "region": "us-east-1" } } } } ``` ### Observed behavior ```bash $ env -u AWS_ACCESS_KEY_ID -u AWS_SECRET_ACCESS_KEY -u AWS_SESSION_TOKEN \ -u AWS_PROFILE -u AWS_BEARER_TOKEN_BEDROCK -u AWS_WEB_IDENTITY_TOKEN_FILE \ OPENCODE_CONFIG="/path/to/opencode.json" \ opencode run -m "amazon-bedrock/anthropic.claude-opus-4-6-v1" "ping" Error: AWS SigV4 authentication requires AWS credentials... Original error: AWS access key ID setting is missing... ``` Command that should work when static creds are set (uses the normal AWS env vars; in ECS/Fargate these are typically injected automatically) ```bash $ OPENCODE_CONFIG="/path/to/opencode.json" \ opencode run -m "amazon-bedrock/anthropic.claude-opus-4-6-v1" "ping" ``` ### Expected If `amazon-bedrock` is specified as a provider and AWS_CONTAINER_CREDENTIALS_RELATIVE_URI is set, Bedrock should authenticate via the AWS SDK credential chain without needing to inject AWS_ACCESS_KEY_ID directly. The following analysis is from Codex: ### Additional verification - opencode models lists Bedrock models even when only the container credential URI is present: ``` env -u AWS_PROFILE -u AWS_ACCESS_KEY_ID -u AWS_WEB_IDENTITY_TOKEN_FILE -u AWS_BEARER_TOKEN_BEDROCK \ -u AWS_CONTAINER_CREDENTIALS_FULL_URI -u AWS_CONTAINER_CREDENTIALS_RELATIVE_URI \ OPENCODE_CONFIG="/path/to/opencode.json" opencode models ``` - opencode run succeeds when standard AWS env creds are set (same config): ``` OPENCODE_CONFIG="/path/to/opencode.json" opencode run -m "amazon-bedrock/anthropic.claude-opus-4-6-v1" "ping" ``` ### Likely root cause In packages/opencode/src/provider/provider.ts, the Bedrock loader only autoloads if one of: - AWS_PROFILE - AWS_ACCESS_KEY_ID - AWS_BEARER_TOKEN_BEDROCK - AWS_WEB_IDENTITY_TOKEN_FILE is present. It does not consider AWS_CONTAINER_CREDENTIALS_{RELATIVE,FULL}_URI, so the loader never wires the SDK credential chain in environments that rely on the container credentials endpoint. Even though the provider appears in config, the loader doesn’t initialize because autoload is gated on env hints. ### Fix needed The Bedrock provider should initialize when it is explicitly configured in opencode.json, even if no env-based credential hints are present. That should be sufficient to trigger fromNodeProviderChain(...) so the AWS SDK can discover container credentials. Additionally (or as a fallback), treat AWS_CONTAINER_CREDENTIALS_RELATIVE_URI or AWS_CONTAINER_CREDENTIALS_FULL_URI as a valid autoload signal. ### Plugins None ### OpenCode version 1.1.53 ### Steps to reproduce Run `opencode run -m "amazon-bedrock/anthropic.claude-opus-4-6-v1` in the description with AWS_CONTAINER_CREDENTIALS_RELATIVE_URI specified, but without AWS_ACCESS_KEY_ID, etc, and using the following config: ```json { "$schema": "https://opencode.ai/config.json", "provider": { "amazon-bedrock": { "options": { "region": "us-east-1" } } } } ``` ### Screenshot and/or share link _No response_ ### Operating System Linux -- Debian 12 (Bookworm) ### Terminal _No response_
yindo added the bug label 2026-02-16 18:11:19 -05:00
yindo closed this issue 2026-02-16 18:11:19 -05:00
yindo commented 2026-02-16 18:11:20 -05:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Feb 10, 2026):

This issue might be a duplicate of existing issues. Please check:

  • #8559: "fix(provider): Enable credential_process and default profile support for Amazon Bedrock" - This directly addresses the same root cause: the guard clause in the Bedrock provider loader that prevents credential chain discovery when no explicit credential environment variables are present. Your issue specifically highlights the AWS_CONTAINER_CREDENTIALS_* case, which is another scenario blocked by the same guard clause.
@github-actions[bot] commented on GitHub (Feb 10, 2026): This issue might be a duplicate of existing issues. Please check: - #8559: "fix(provider): Enable credential_process and default profile support for Amazon Bedrock" - This directly addresses the same root cause: the guard clause in the Bedrock provider loader that prevents credential chain discovery when no explicit credential environment variables are present. Your issue specifically highlights the `AWS_CONTAINER_CREDENTIALS_*` case, which is another scenario blocked by the same guard clause.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
acp
bad
bug
discussion
docs
documentation
enhancement
extension
good first issue
growth
help-wanted
mcp
model-problem
needs:compliance
nix
opentui
perf
pull-request
Mirrored from GitHub Pull Request
 tui
web
windows
zen
No Label bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#8987
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?