Skip to content

fix(media-understanding): use aws-sdk credentials for bedrock image models#97525

Closed
CrypticDriver wants to merge 1 commit into
openclaw:mainfrom
CrypticDriver:fix/bedrock-image-aws-sdk-auth
Closed

fix(media-understanding): use aws-sdk credentials for bedrock image models#97525
CrypticDriver wants to merge 1 commit into
openclaw:mainfrom
CrypticDriver:fix/bedrock-image-aws-sdk-auth

Conversation

@CrypticDriver

Copy link
Copy Markdown

What Problem This Solves

When agents.defaults.imageModel points at an amazon-bedrock model and the provider uses auth: "aws-sdk", the image-understanding tool fails with:

No API key resolved for provider "amazon-bedrock" (auth mode: aws-sdk, checked: aws-sdk default chain).

…even though the same bedrock model works fine for normal chat.

aws-sdk auth resolves credentials lazily through the AWS SDK credential chain (env vars, shared ~/.aws files, EC2 instance-role IMDS, ECS container role), so the resolved API key is legitimately empty. The bedrock-converse provider stream signs requests with those SDK credentials and never consumes an API key, and the main chat path never calls requireApiKey for aws-sdk.

The image path in src/media-understanding/image.ts (prepareResolvedImageRuntime) unconditionally called requireApiKey(...), which throws MissingProviderAuthError whenever the key is empty. This wrongly blocked image analysis for every bedrock deployment that relies on instance-role / default-profile / SSO credentials (no static key in env) — chat worked, the image tool did not.

Evidence

Repro before the fix (EC2 host, bedrock credentials via instance role; chat works, image tool fails):

  • Config: imageModel = amazon-bedrock/global.anthropic.claude-opus-4-8, provider auth: "aws-sdk".
  • Image tool result: All image models failed (2): amazon-bedrock/global.anthropic.claude-opus-4-8: No API key resolved for provider "amazon-bedrock" (auth mode: aws-sdk, checked: aws-sdk default chain). | amazon-bedrock/global.anthropic.claude-opus-4-7: No API key resolved ...

Fix (src/media-understanding/image.ts) — branch on auth mode so aws-sdk keeps an empty key and defers to the SDK chain, while all other modes still require a usable key:

let apiKey =
  apiKeyInfo.mode === "aws-sdk"
    ? (apiKeyInfo.apiKey ?? "")
    : requireApiKey(apiKeyInfo, model.provider);

Regression test added in src/media-understanding/image.test.ts — "lets amazon-bedrock image models use aws-sdk credentials without an API key" — asserts that for an aws-sdk bedrock model the path (1) never calls requireApiKey, (2) stores an empty runtime key (setRuntimeApiKey("amazon-bedrock", "")), and (3) reaches the provider completion with apiKey: "".

Local test run (added test + existing suite, on the EC2 host above):

$ node node_modules/.bin/vitest run --config test/vitest/vitest.media-understanding.config.ts src/media-understanding/image.test.ts
 ✓ media-understanding  src/media-understanding/image.test.ts (30 tests) 2475ms
 Test Files  1 passed (1)
      Tests  30 passed (30)

…odels

The image-understanding path called requireApiKey() unconditionally in
prepareResolvedImageRuntime(). For amazon-bedrock providers using
auth: "aws-sdk", the resolved API key is legitimately empty because
credentials come from the AWS SDK chain (env vars / shared ~/.aws files /
EC2 instance-role IMDS / ECS container role). The bedrock-converse stream
signs requests with those SDK credentials and never consumes an API key,
and the main chat path never calls requireApiKey for aws-sdk.

Requiring a key here made image analysis fail with
"No API key resolved for provider ... (auth mode: aws-sdk ...)" on every
bedrock deployment without a static key in env, while chat worked.

Now aws-sdk mode keeps an empty key and defers to the SDK chain; all other
auth modes still require a usable key. Adds a regression test.
@clawsweeper

clawsweeper Bot commented Jun 28, 2026

Copy link
Copy Markdown
Contributor

Thanks for the context here. I swept through the related work, and this is now duplicate or superseded.

The image fix is useful, but #72092 is the stronger open landing path: it is mergeable, proof-positive, linked to the canonical issue, and covers the same image failure plus sibling audio/video media auth paths.

Root-cause cluster
Relationship: superseded
Canonical: #72092
Summary: This PR is superseded by the broader open proof-positive PR for the canonical Bedrock media aws-sdk missing-key issue.

Members:

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

Canonical path: #72031 reports the same Bedrock aws-sdk image/media missing-key failure and remains open with linked fix PR context.

So I’m closing this here and keeping the remaining discussion on #72092 and #72031.

Review details

Best possible solution:

Close this PR in favor of reviewing and landing #72092, which is the broader proof-positive fix for the canonical Bedrock media aws-sdk auth issue.

Do we have a high-confidence way to reproduce the issue?

Yes. Source inspection and the canonical issue show that Bedrock aws-sdk auth resolves without a static key and current main then calls requireApiKey in the image runtime before the SDK credential chain can run.

Is this the best way to solve the issue?

No. This PR is a plausible image-only fix, but #72092 is the better landing path because it covers the same image failure, includes stronger live proof, and handles sibling audio/video media paths for the same auth class.

Security review:

Security review cleared: No supply-chain, workflow, dependency, secret-handling, or new code-execution surface is added by this two-file runtime/test diff.

AGENTS.md: found and applied where relevant.

What I checked:

Likely related people:

  • vincentkoc: Live file history shows recent image-runtime changes including shared single-image request mapping and timeout fixes in src/media-understanding/image.ts. (role: recent image runtime contributor; confidence: medium; commits: 3939da7a094b, 88b21fc30b4a; files: src/media-understanding/image.ts)
  • steipete: Recent history shows major agent-runtime/provider refactors and media runner/auth documentation around the affected provider-auth boundary. (role: shared auth and media runner area contributor; confidence: medium; commits: bb46b79d3c14, 5f7095f8be25; files: src/media-understanding/runner.entries.ts, src/agents/simple-completion-runtime.ts, docs/gateway/authentication.md)
  • truffle-dev: Authored the viable open PR that closes the canonical issue and implements the same image fix plus audio/video keyless media auth coverage. (role: canonical fix candidate owner; confidence: high; commits: f4d073ecbf17; files: src/media-understanding/image.ts, src/media-understanding/runner.entries.ts, src/media-understanding/runner.aws-sdk.test.ts)

Codex review notes: model internal, reasoning high; reviewed against 27c1685f106d.

@clawsweeper clawsweeper Bot added rating: 🦪 silver shellfish Thin PR readiness signal; proof, validation, or implementation needs work. status: 📣 needs proof The PR needs real behavior proof before ClawSweeper can clear the contributor ask. P1 High-priority user-facing bug, regression, or broken workflow. labels Jun 28, 2026
@clawsweeper

clawsweeper Bot commented Jun 28, 2026

Copy link
Copy Markdown
Contributor

ClawSweeper applied the proposed close for this PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

P1 High-priority user-facing bug, regression, or broken workflow. rating: 🦪 silver shellfish Thin PR readiness signal; proof, validation, or implementation needs work. size: S status: 📣 needs proof The PR needs real behavior proof before ClawSweeper can clear the contributor ask.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants