dev scripts pass --conditions=browser, silently breaking node-only deps (Bedrock returns an empty stream)

I've been running the TUI from source and prompts started coming back empty. No text, no error, the session just goes quiet.

https://github.com/user-attachments/assets/d1efa258-6548-4778-9650-89a2af951a63

Took a while to track down because nothing is logged. The assistant message gets stored like this:

finish: "unknown"
tokens: { input: 0, output: 0 }
parts:  step-start, step-finish

No text part, no error part. prompt.ts:1111 treats any truthy finish reason as terminal, "unknown" included, so the loop exits having written nothing. Title generation dies the same way, which is why the session title in the video is still a raw timestamp.

The cause is --conditions=browser in the dev scripts:

package.json:9                    "dev": "bun run --cwd packages/opencode --conditions=browser src/index.ts"
packages/opencode/package.json:15 "dev": "bun run --conditions=browser ./src/index.ts"

Same source, same model, same credentials, only the flag differs:

$ bun run --cwd packages/opencode --conditions=browser src/index.ts run "reply with the single word OK"
> build · us.anthropic.claude-sonnet-4-6
                                            <- empty, finish "unknown", 0 tokens

$ bun run --cwd packages/opencode src/index.ts run "reply with the single word OK"
> build · us.anthropic.claude-sonnet-4-6
OK

This is not a Bedrock bug and I'd rather it not get triaged as one. The flag turns on the browser export condition for the entire dependency graph, and roughly 210 packages in this tree ship a browser build. Bedrock is just the one I happened to hit.

It breaks through auth, not through the provider. @ai-sdk/amazon-bedrock is plain fetch-based and resolves identically either way, but @aws-sdk/credential-providers pulls in @smithy/shared-ini-file-loader, which does have a browser build. Without credentials in the env you get it loudly:

config.parseKnownFiles is not a function.
(In 'config.parseKnownFiles(init)', 'config.parseKnownFiles' is a Symbol)

With credentials the chain short-circuits before that and you get silence instead.

Other providers happen to escape because none of them need a node-only auth SDK — google-auth-library has no browser condition, so Vertex is fine. But tar-stream, readable-stream, @octokit/*, @opentelemetry/* and @azure/* all ship browser builds too. I haven't checked whether any of those actually break. The mechanism doesn't care which package it hits.

This has bitten before, too. #20416 was a blank TUI under the same flag, and the fix in #20413 mentions Provider.defaultLayer being undefined under this condition. That got worked around rather than removed.

Worth noting the release build has never passed this flag — it uses conditions: ["bun", "node"]. So dev resolves modules differently from every shipped binary, which is why this only hits people running from source. Removing the flag doesn't move dev somewhere untested, it moves dev onto what production already runs.

The fix, and one ordering constraint

Dropping it from both dev scripts works, but there's a dependency worth knowing about. solid-js sends the node condition to its server build, so it relies on @opentui/solid's preload, which installs an onLoad hook rewriting dist/server.js to dist/solid.js. Bun reads bunfig.toml from the cwd, so that preload only applies inside the repo:

cwd in repo,      no flag  ->  REACTIVE
cwd outside repo, no flag  ->  DEAD (SSR build)
cwd outside repo, browser  ->  REACTIVE

bun run dev always runs inside the repo so the scripts as written are fine, but #40230 makes this unconditional by importing the preload at the entrypoint. Cleanest order is that first, then drop the flag.

One caveat on that: the flag being redundant depends on the @opentui/solid version shipping the onLoad hook (0.4.5 does). The flag and the bunfig preload were actually added in the same commit, 96bdeb3c7, so it may well have been necessary before the hook existed and just never got cleaned up. Nothing in the repo encodes that dependency, so downgrading the catalog pin would silently regress it.

I have the two-line change running locally against Bedrock and confirmed the TUI renders normally without the flag. Happy to open a PR, though the sequencing against #40230 felt like a maintainer call.

Separately, the silent failure deserves its own fix. prompt.ts:1111 exits on "unknown" while prompt.ts:1295 deliberately excludes it, so an empty stream from any provider gives you a blank screen and no error. Attaching an error part on an empty finish would cover it — making "unknown" non-terminal would just spin the loop and bill a request per iteration.

Environment

• bun 1.3.14, macOS (darwin 25.5.0)
• opencode 1.18.12, running from source
• provider: amazon-bedrock, us.anthropic.claude-sonnet-4-6