Regression: opencode 1.16 is broken for AWS bedrock provider with SSO login

[intentionally-left-nil]

Description

Opencode returns this error when trying to use inference:

AWS credential provider failed: E is not a function. (In 'E(e)', 'E' is a Symbol). Please ensure your credential provider returns valid AWS credentials with accessKeyId and secretAccessKey properties

This is a regression from 1.15.13

Plugins

none

OpenCode version

1.16.0

Steps to reproduce

Have this in your config:

"provider": {
    "amazon-bedrock": {
	"options": {
	  "region": "us-east-1"
	}
    }
  },

along with the proper AWS profile set up (we have SSO-backed auth in case it matters), then run opencode run "say hello"

Screenshot and/or share link

No response

Operating System

OSX Tahoe 26.5

Terminal

alacritty

[intentionally-left-nil]

From local investigation, the unminified error is this:

ERROR 2026-06-06T20:56:27 +1ms service=session.processor session.id=ses_161470998ffescv6VjCqQfYKWN
messageID=msg_e9eb8f676001RMOMSDiO11CMhL error=AWS credential provider failed: config.parseKnownFiles is not a
function. (In 'config.parseKnownFiles(init)', 'config.parseKnownFiles' is a Symbol). Please ensure your credential provider
returns valid AWS credentials with accessKeyId and secretAccessKey properties. stack=Error: AWS credential provider
failed: config.parseKnownFiles is not a function. (In 'config.parseKnownFiles(init)', 'config.parseKnownFiles' is a Symbol).
Please ensure your credential provider returns valid AWS credentials with accessKeyId and secretAccessKey properties.

[intentionally-left-nil]

AI assisted analysis points to some fun CJS vs module bundling issues. I personally doubt this is an upstream bun issue, but it does look like it's something to do with the bundling

Claude analysis

Found it. @aws-sdk/token-providers CJS uses await import('@aws-sdk/nested-clients/sso-oidc') — a dynamic ESM import(). That loads the dist-es version of nested-clients/sso-oidc, which in turn does import { ... } from "@smithy/core/config" as ESM. Bun caches that module as an ESM namespace object. Then when credential-provider-ini CJS does var config = require('@smithy/core/config'), Bun hands back the already-cached ESM namespace — where named exports are Symbol-keyed, not string-keyed.
This is a Bun bug: mixing require() and dynamic import() of the same module within the same runtime causes the module cache to return an ESM namespace object to a CJS require() call, breaking property access.
The workaround is to ensure @aws-sdk/credential-providers and its whole dep tree load consistently as ESM. The cleanest way: use the dist-es entry directly for the packages that have the mismatch, by adding overrides in package.json to point @aws-sdk/token-providers and @aws-sdk/credential-provider-ini at their ESM builds — or, more practically, file this as a Bun bug and in the meantime avoid fromNodeProviderChain in favour of building the credential chain manually using only ESM-safe providers.

[intentionally-left-nil]

This git bisects to 76ee87ead84ab5c5583074a19ea0894c5e8e361a

which is a very large commit unfortunately.

[intentionally-left-nil]

Okay, so some more findings: The git bisect here was done with bun dev --print-logs run "say hello" and it turns out bun dev mode is affected by this in a way that the production build is potentially not. Here's some more AI analysis that feels right to me:

AI root cause analysis

Near the bottom of the browser build:

const no = Symbol.for("node-only");
const parseKnownFiles = no;

Every node-only export is deliberately set to Symbol.for("node-only") in the browser CJS build. @smithy/core@3.24.5 intentionally stubs out filesystem/node-only APIs in its browser condition export as Symbols. When bun dev runs with --conditions=browser, Bun resolves the browser entry in the exports map — which gives dist-cjs/submodules/config/index.browser.js — and parseKnownFiles is that Symbol stub.
The parent commit did not have this problem because @aws-sdk/credential-providers@3.993.0 (the old version) pinned credential-provider-ini@3.972.29, which depended on @smithy/shared-ini-file-loader and @smithy/property-provider directly as separate packages — never routing through @smithy/core/config.

The bisect commit bumped @aws-sdk/credential-providers to 3.1057.0, which requires credential-provider-ini@^3.972.46. That version consolidated its deps into @smithy/core/config, a subpath that has a browser stub returning Symbols for all node-only APIs.

So, at the very least, there's a dev dependency with opencode. The next thing for me to figure out is whether there is a separate (possibly) related problem for the production build, or if the homebrew version of opencode (which is what I am using) is misconfigured to use the browser build, rather than what opencode directly provides when building.

[intentionally-left-nil]

Okay, I have put all of the pieces together. There are two related issues going on. I'll leave this issue as open until a maintainer takes a peek, because there's still a problem during development version, even if end users are unaffected since 1.16.2

Summary

browser-mode bundling is broken for opencode + amazon-bedrock since 1.15.3 due to a fragility in how the code resolution works. This fragility exists today, and any contributor to the codebase running bun dev will hit the bug metioned in this issue even today.

For users of distributions, here is the status:
1.15.3 - No bug
1.16.0 - Bug introduced by the changing dependencies
1.16.2 - Bug fixed by switching to node mode for resolution

Note: Homebrew users are stuck on 1.16.0 until homebrew gets their PR landed

More details

Fundamentally, the module resolution code of opencode when using browser mode is just extremely fragile. Dependencies which pull in other dependencies are liable to cause bundling issues. The bisecting commit 76ee87ead84ab5c5583074a19ea0894c5e8e361a just happened to cause a new set of dependencies for the amazon bedrock path which triggered this.

This fragility exists today in the main branch, and can easily be reproduced by running bun dev when using the amazon-bedrock provider.

Browser mode is going to always cause issues with smithy (and perhaps other modules) for any dependency that explicitly has a split browser version vs node version. The AWS SDK and Smithy packages ship separate browser builds that deliberately stub out every node-only API with Symbol.for("node-only"). When you run a Node.js CLI with --conditions=browser, any package that ships a browser build will silently swap in those stubs. causing this blowup

[OpeOginni]

@intentionally-left-nil so you just need to upgrade, if it works you can close the issue please

[intentionally-left-nil]

@OpeOginni As mentioned, that will fix the released version, but not any developer working in the codebase using bun dev