You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
TUI crashes with "[Reconciler] Unknown component type: spinner" during prompt render.
Steps to reproduce
Build OpenCode locally from branch feature/session-directory-filtering (HEAD 4bbb0df, based on dev bded900).
Run the built binary (oc-custom / opencode).
TUI crashes on startup.
Actual
Error: [Reconciler] Unknown component type: spinner
at createElement (../../node_modules/.bun/@[email protected]+897ebc1644d3edd0/node_modules/@opentui/solid/index.js:521:17)
at children (src/cli/cmd/tui/component/prompt/index.tsx:939:26)
at <anonymous> (../../node_modules/.bun/[email protected]/node_modules/solid-js/dist/dev.js:1531:21)
at runComputation (../../node_modules/.bun/[email protected]/node_modules/solid-js/dist/dev.js:742:22)
at updateComputation (../../node_modules/.bun/[email protected]/node_modules/solid-js/dist/dev.js:724:3)
at readSignal (../../node_modules/.bun/[email protected]/node_modules/solid-js/dist/dev.js:660:67)
at <anonymous> (../../node_modules/.bun/@[email protected]+897ebc1644d3edd0/node_modules/@opentui/solid/index.js:148:62)
at runComputation (../../node_modules/.bun/[email protected]/node_modules/solid-js/dist/dev.js:742:22)
at updateComputation (../../node_modules/.bun/[email protected]/node_modules/solid-js/dist/dev.js:724:3)
at createRenderEffect (../../node_modules/.bun/[email protected]/node_modules/solid-js/dist/dev.js:240:75)
Expected
TUI should render without crashing.
Environment
macOS 26.3 (25D5087f), arm64
Bun 1.3.5
package version: 1.1.8
@opentui/solid 0.1.70 in bun.lock (stack trace shows @opentui/[email protected] path)
This issue might be a duplicate of existing issues. Please check:
opentui: fatal: Anchor does not exist #7061: opentui: fatal: Anchor does not exist - Another @opentui/solid reconciler error with very similar stack trace pattern (reconcileArrays → insertExpression → createRenderEffect)
TUI Crashes #4606: TUI Crashes - TUI crash after component rendering with similar reconciliation failure
TUI crashes during prompt edit #3749: TUI crashes during prompt edit - Related crash in prompt/index.tsx (the same file mentioned in your stack trace)
The root cause appears to be related to @opentui/solid component registration or version incompatibility. Note that your stack trace shows @opentui/[email protected] but bun.lock lists 0.1.70 - this version mismatch may be significant.
Feel free to ignore if your specific case differs from these issues.
I ran into this exact same error today after updating my local branch. It looks like an issue with Bun's dependency caching or a stale version of the SolidJS TUI reconciler getting stuck in node_modules.
Solution:
A complete clean install fixed the crash immediately. Here are the steps I took:
...
Solution: A complete clean install fixed the crash immediately. Here are the steps I took:
1. Delete the existing modules: rm -rf node_modules
2. Reinstall packages: bun install
3. Rebuild the project: bun run build --single
Hitting this on the official prebuilt release binary (v1.14.41, Linux x64),
which suggests this isn't just a local dev / Bun cache issue - the duplicate is shipped in the release.
Root cause
The release tarball includes two copies of @opentui/solid in node_modules:
node_modules/@opentui/solid → v0.2.2 (used by opencode)
node_modules/opentui-spinner/node_modules/@opentui/solid → v0.1.105 (used by opentui-spinner)
opentui-spinner declares @opentui/solid: ^0.1.49 as a peer dependency, while the workspace catalog pins @opentui/solid to 0.2.2. Since 0.2.2 doesn't satisfy ^0.1.49, Bun installs a separate copy under opentui-spinner/node_modules/.
opentui-spinner/dist/solid.mjs calls extend({ spinner: ... }), but that extend resolves to the v0.1.105 instance and registers the
component on its own componentCatalogue. The TUI itself uses v0.2.2, whose catalogue never receives the registration. When <spinner> is
rendered, the v0.2.2 reconciler throws Unknown component type: spinner.
I verified this by inspecting strings in the compiled binary — both extend({ spinner: ... }) calls are present, but they target different
module instances. This also explains why rm -rf node_modules && bun install && bun run build --singlesometimes works for people: depending
on the resolver state, Bun occasionally hoists a single copy and the bug disappears, but it isn't deterministic.
Verified fix
Adding the following to the rootpackage.jsonoverrides, then bun install --force and rebuilding, eliminates the duplicate and fixes
the crash:
"overrides": {
"@opentui/solid": "0.2.2",
"@opentui/core": "0.2.2"
}
After this, node_modules/opentui-spinner/node_modules/@opentui/ no longer exists, and the rebuilt binary renders the spinner correctly. Confirmedlocally on Linux x64 with v1.14.41.Suggested upstream fixes1. Add the override above to this repo so prebuilt releases never ship the duplicate, or2. Bump opentui-spinner to widen its peer dep range (e.g. ^0.1.49 || ^0.2.0) - the extend() API used by opentui-spinner/dist/solid.mjs is identical between v0.1.x and v0.2.2, so no code change in the spinner itself should be needed.
Activity
github-actions commentedon Jan 9, 2026
This issue might be a duplicate of existing issues. Please check:
The root cause appears to be related to @opentui/solid component registration or version incompatibility. Note that your stack trace shows @opentui/[email protected] but bun.lock lists 0.1.70 - this version mismatch may be significant.
Feel free to ignore if your specific case differs from these issues.
kommander commentedon Jan 9, 2026
Are you linking opentui locally for dev?
Zhanbingli commentedon Feb 25, 2026
I ran into this exact same error today after updating my local branch. It looks like an issue with Bun's dependency caching or a stale version of the SolidJS TUI reconciler getting stuck in
node_modules.Solution:
A complete clean install fixed the crash immediately. Here are the steps I took:
rm -rf node_modulesbun installbun run build --singleHope this helps anyone who gets stuck on this!
paulgear commentedon Mar 18, 2026
This worked for me - thanks!
Switch bun install to isolated linker to fix TUI spinner crash
Recompute opencode node_modules hash for isolated linker layout
presire commentedon May 9, 2026
Hitting this on the official prebuilt release binary (v1.14.41, Linux x64),
which suggests this isn't just a local dev / Bun cache issue - the duplicate is shipped in the release.
Root cause
The release tarball includes two copies of
@opentui/solidinnode_modules:node_modules/@opentui/solid → v0.2.2 (used by opencode)
node_modules/opentui-spinner/node_modules/@opentui/solid → v0.1.105 (used by opentui-spinner)
opentui-spinnerdeclares@opentui/solid: ^0.1.49as a peer dependency, while the workspace catalog pins@opentui/solidto0.2.2. Since0.2.2doesn't satisfy^0.1.49, Bun installs a separate copy underopentui-spinner/node_modules/.opentui-spinner/dist/solid.mjscallsextend({ spinner: ... }), but thatextendresolves to the v0.1.105 instance and registers thecomponent on its own
componentCatalogue. The TUI itself uses v0.2.2, whose catalogue never receives the registration. When<spinner>isrendered, the v0.2.2 reconciler throws
Unknown component type: spinner.I verified this by inspecting strings in the compiled binary — both
extend({ spinner: ... })calls are present, but they target differentmodule instances. This also explains why
rm -rf node_modules && bun install && bun run build --singlesometimes works for people: dependingon the resolver state, Bun occasionally hoists a single copy and the bug disappears, but it isn't deterministic.
Verified fix
Adding the following to the root
package.jsonoverrides, thenbun install --forceand rebuilding, eliminates the duplicate and fixesthe crash:
ketut commentedon Jun 19, 2026
In my case it's working when i change opentui-spinner 0.0.7 to opentui-spinner 0.0.6 in packages.json
github-actions commentedon Aug 19, 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.