[shunkakinoki]

Issue for this PR

Closes #55949

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

The TUI sends its first RPC calls (fetch, then checkUpgrade) to the server worker as soon as the worker is created. The worker only sets onmessage in Rpc.listen(rpc), on its last line, after its module evaluation finishes, including the top-level await in core/src/global.ts. Bun drops messages that arrive at a worker during that window, and call() never rejects, so the TUI waits forever and never draws.

Fix, all in util/rpc.ts:

• listen() posts rpc.ready right after setting onmessage.
• client() holds every request until it sees rpc.ready.

Nothing else changes. Worker-to-main events were never affected, because the main thread sets its handler synchronously after new Worker.

How did you verify your code works?

• New test/util/rpc.test.ts: a fixture worker emits started, then sits in a top-level await before calling Rpc.listen. The test calls into it during that await. Without the fix it times out; with it, it passes.
• Plain Bun repro from the issue: ping lost 5/5 without a handshake, answered 5/5 with one. Across three timing variants on Linux: 15/15 lost vs 15/15 delivered.
• On our agent fleet (1.18.31, unattended TUIs on Linux), 13 sessions in 6.5 hours never drew. Each stuck process matched this: both threads idle, no creating instance log line, database never opened.
• bun run typecheck in packages/opencode passes.

Screenshots / recordings

Not a UI change.

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

🤖 Generated with Claude Code

[github-actions]

The following comment was made by an LLM, it may be inaccurate:

[HootRock]

AI-assisted supplemental Windows verification of 846f0b58 against its current v1 base e03feec3, using Bun 1.4.2.

With Git-blob-verified copies of the actual dependency-free RPC module, the unchanged new upstream regression plus four independent real-Worker tests give 5 passes on head versus 2 passes / 3 timeouts on base. The additional cases cover queued calls with out-of-order responses, separate delayed workers, post-listen JSON values (including CJK/emoji), and event delivery/unsubscribe.

This validates the protocol repair on native Windows with simulated module-evaluation delay. It does not measure shipped TUI startup, fleet failure rates, Bun 1.4.3, full-package tests or types. The source review includes the TUI's immediate client attachment and the worker's final Rpc.listen call. The v1 release-policy decision remains with maintainers.

reviewed and tested locally.

[shunkakinoki]

Closing: this race lives in the 1.x TUI's Worker + util/rpc.ts postMessage handshake. In v2 (checked at v2.0.30) the TUI no longer spawns a Worker; it talks to a background or --standalone server over HTTP, so there is no worker RPC to race. We are moving our hosts to v2 instead of carrying this patch.