v0.7.0 & v0.7.1 release tarball is missing dist/bundle/amazon-bedrock.js, breaking the amazon-bedrock provider

[HenryL-system1]

Description

The officially published v0.7.0 release artifact fails at runtime for the amazon-bedrock provider:

Error: Cannot find module '/opt/homebrew/lib/node_modules/prime-agent/dist/bundle/amazon-bedrock.js' imported from
/opt/homebrew/lib/node_modules/prime-agent/dist/bundle/chunk-ALQBG3TN.js

Root cause

dist/bundle/chunk-ALQBG3TN.js dynamically imports the bedrock provider chunk:

bedrockProviderModulePromise ||= importNodeOnlyProvider("./amazon-bedrock.js").then(...)

but dist/bundle/amazon-bedrock.js is not present in the shipped package. Every other provider entry point exists as its own chunk (anthropic-JMWPKDC4.js, google-vertex-SQF6LM63.js, mistral-OBA3N6GZ.js, openai-completions-5PBGGQ35.js, etc.) — only the bedrock one is missing.

This affects both distribution channels, which serve byte-identical artifacts:

• The R2 CDN URL used by prime-agent update (https://pub-728493de92a943e2a9b2d17b4719f318.r2.dev/releases/v0.7.0/prime-agent-0.7.0.tgz)
• The GitHub release asset prime-agent-0.7.0.tgz on the v0.7.0 release

Both have SHA256 88b6578518c72cd51a825bc80f28e0fef9a64c67de4a7d6fd7afd7ca1b34da0b, confirming it's the same build, not a corrupted local install.

Likely tie-in to #651

I believe this was caused by the same underlying issue reported in #651: @aws-sdk/core@^3.977.6 did not exist on the npm registry at the time v0.7.0 was built in CI. That issue was closed because the npm package now exists and a fresh npm install succeeds — but the already-published v0.7.0 tarball was never rebuilt/republished, so it still ships without the bedrock bundle chunk. It looks like the build step for that entry point failed silently (e.g. esbuild couldn't resolve the then-missing @aws-sdk/core) without failing the overall build/release.

Note: dist/bun/register-bedrock.js (used by the Bun-based path) is present and looks fine — this appears to be specific to the Node bundle output.

Reproduction

curl -fsSL https://app.primeintellect.ai/prime-agent/install.sh | sh
# settings.json: { "defaultProvider": "amazon-bedrock", ... }
prime-agent
# -> Error: Cannot find module '.../dist/bundle/amazon-bedrock.js'

prime-agent update --force does not help since it re-fetches the same pinned, broken v0.7.0 tarball.

Suggested fix

Rebuild and republish the v0.7.0 tarball (or cut v0.7.1) now that @aws-sdk/core@3.977.6 is available, and add a CI check that fails the build if any provider chunk referenced by chunk-*.js's importNodeOnlyProvider calls is missing from the published dist/bundle/ output.

Environment

• OS: macOS (Apple Silicon, /opt/homebrew)
• Install method: install.sh / prime-agent update --force
• prime-agent --version: 0.7.0

[ItayCoCo]

This also makes me stuck, not using the harness cause of that

[fettpl]

This also blocks the open official Homebrew formula: Homebrew/homebrew-core#297372 installs the same v0.7.0 asset and SHA256, so a merged formula would ship the broken Bedrock provider.

@badlogic please cut a corrected stable release rather than replacing the existing asset in place; Homebrew needs an immutable versioned URL and checksum. The end-to-end packaging work is tracked in #843.

[seankumar-tl]

This is still broken on the released v0.7.1, so the scope here is wider than 0.7.0. Might be worth updating the title.

Fresh install of 0.7.1 (published Aug 7 18:39 UTC):

Error: Cannot find module '/Users/…/lib/node_modules/prime-agent/dist/bundle/amazon-bedrock.js'
imported from /Users/…/lib/node_modules/prime-agent/dist/bundle/chunk-VNU2AJHD.js

dist/bundle/ has all eight other providers, each content-hashed, and no amazon-bedrock.js.

That rules out the #651 tie-in as the cause. v0.7.1 was built well after @aws-sdk/core@3.977.6 landed on the registry, and the chunk still isn't emitted. The cause is structural: importNodeOnlyProvider = (specifier) => import(specifier) hides the specifier from esbuild, so it never emits or rewrites that entry point regardless of how clean the dependency tree is at build time. Rebuilding or cutting another release won't fix it on its own. #860 looks like the actual fix.

Which also means #843 / Homebrew/homebrew-core#297372 doesn't get resolved by bumping the formula to 0.7.1. It would ship the same broken provider.

For anyone still blocked and not wanting to wait on a release: the provider does ship, it's just in the wrong place, so you can create the file the bundle is looking for and re-export it.

// <prefix>/lib/node_modules/prime-agent/dist/bundle/amazon-bedrock.js
export { streamBedrock, streamSimpleBedrock } from "../../node_modules/@earendil-works/pi-ai/dist/providers/amazon-bedrock.js";

Don't copy the provider file itself, it has relative imports (../models.js, ../utils/event-stream.js) that only resolve from its own directory. Re-exporting leaves it in place so those and @aws-sdk/client-bedrock-runtime resolve normally. The caveat is that you end up with a second copy of the pi-ai module graph next to the bundled one, so I can't vouch for cross-instance class identity, but Bedrock streaming has been working fine for me. Any reinstall wipes it.

Env: node v24.18.1, npm 12.0.2, macOS 15.4.1 arm64, installed via install.sh.

[fettpl]

The source-side fix is already complete in #860, so another implementation PR would duplicate active work. It adds amazon-bedrock as an explicit bundle entry and makes the build fail when a referenced node-only provider asset is absent.

The remaining acceptance path is:

1. approve workflow run 31189426821, which is still action_required because fix(coding-agent): include Bedrock in Node bundle #860 originates from a fork;
2. review and merge fix(coding-agent): include Bedrock in Node bundle #860;
3. publish a new stable release; and
4. verify the published archive contains dist/bundle/amazon-bedrock.js and that the module imports successfully before closing this issue.

@badlogic could you approve the workflow and review #860? The issue title should also include v0.7.1, since that released artifact has the same defect.

[SaloQT]

Adding a Windows data point, plus one trigger I haven't seen mentioned: you don't have to configure Bedrock at all to get hit by this.

Provider auto-detection treats the presence of any AWS credential in the environment as "Bedrock is available" - AWS_PROFILE, AWS_ACCESS_KEY_ID, AWS_BEARER_TOKEN_BEDROCK, AWS_CONTAINER_CREDENTIALS_RELATIVE_URI, AWS_CONTAINER_CREDENTIALS_FULL_URI, AWS_WEB_IDENTITY_TOKEN_FILE - and with nothing else configured it picks Bedrock with default model us.anthropic.claude-opus-4-6-v1. So on a machine that merely has AWS_PROFILE exported, which is normal for anyone who touches AWS and has nothing to do with wanting Bedrock, every invocation dies before doing any work:

$ prime-agent -p "hi"
Cannot find module '...\dist\bundle\amazon-bedrock.js'
imported from '...\dist\bundle\chunk-VNU2AJHD.js'

No settings.json change needed to reproduce it, and the profile doesn't even have to be valid - only the variable's presence matters. The error gives no hint that AWS is involved, so it reads as "the tool is broken" rather than "unset an env var", which cost me a fair while to trace. If you don't want Bedrock, unsetting the variable or passing --provider explicitly is enough to sidestep it.

Otherwise just confirming @seankumar-tl's findings hold on Windows too: 0.7.1 tarball pulled straight from the release (SHA256 d68612c83239caafab72cc76c55ac572bfd07a059ea8fbd2a3ddbe1f2b55dcdb, matching the published SHA256SUMS), all eight other provider chunks present and content-hashed, no amazon-bedrock.js, and chunk-VNU2AJHD.js still calling importNodeOnlyProvider("./amazon-bedrock.js"). Their re-export workaround works here as well.

Env: Windows 11 26100, node v24.15.0, global npm install, prime-agent 0.7.1.

[nigel-dev]

Looks like this is still happening on 0.7.2 as well.

[kevinjosethomas]

Hi, thanks for taking the time to report this! Since open sourcing Prime Agent, we’ve received far more Issues than we can reliably triage and maintain. Rather than leave a large backlog that we cannot meaningfully work through, we’re closing the current Issue queue and moving to a discussion-first process.

We have established new contribution guidelines to help us continue iterating on Prime Agent and better manage contributions from the community. Going forward, GitHub Issues will be our maintainer work queue rather than the initial place for public reports and requests. Bug reports, feature requests, questions, and other feedback should begin in GitHub Discussions. Please read the full process documented in our contribution guidelines. Security vulnerabilities should continue to be reported privately according to our security policy.

While we’re closing this backlog, we’re still reviewing it at a high level to identify recurring bugs, useful ideas, and important problems that we should address ourselves. Thanks again for the time you put into this!

[kaluli123123]

Re-verified this against current main: the same gap still reproduces today (dist/bundle/ has no amazon-bedrock.js after a real build). Filed root cause + tested fix in Discussion #1763, per the project's contribution process: #1763