Repository navigation
Regression: opencode 1.16 is broken for AWS bedrock provider with SSO login #31147
Closed as not planned
Description
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
Metadata
Metadata
Assignees
Labels
No labels
Activity
intentionally-left-nil commentedon Jun 6, 2026
From local investigation, the unminified error is this:
[-]Regression: opencode 1.16 is broken for AWS bedrock provider[/-][+]Regression: opencode 1.16 is broken for AWS bedrock provider with SSO login[/+]intentionally-left-nil commentedon Jun 6, 2026
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 commentedon Jun 7, 2026
This git bisects to 76ee87ead84ab5c5583074a19ea0894c5e8e361a
which is a very large commit unfortunately.
intentionally-left-nil commentedon Jun 7, 2026
Okay, so some more findings: The git bisect here was done with
bun dev --print-logs run "say hello"and it turns outbun devmode 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:
Every node-only export is deliberately set to Symbol.for("node-only") in the browser CJS build.
@smithy/core@3.24.5intentionally 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 givesdist-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) pinnedcredential-provider-ini@3.972.29, which depended on@smithy/shared-ini-file-loaderand@smithy/property-providerdirectly as separate packages — never routing through@smithy/core/config.The bisect commit bumped
@aws-sdk/credential-providersto 3.1057.0, which requirescredential-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 commentedon Jun 7, 2026
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 devwill 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
browsermode 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 devwhen 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 commentedon Jun 7, 2026
@intentionally-left-nil so you just need to upgrade, if it works you can close the issue please
intentionally-left-nil commentedon Jun 8, 2026
@OpeOginni As mentioned, that will fix the released version, but not any developer working in the codebase using
bun devfix(close-issues): read target repo from GITHUB_REPOSITORY env var
fix(close-issues): read target repo from GITHUB_REPOSITORY env var (#11)
github-actions commentedon Aug 8, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.