tui: /btw crashes when rendering answer dialog #49777

Activity

1. MarkOgink

   marked TUI crash: PluginProvider is missing #49784 as a duplicate of this issue on Sep 18, 2026
2. cestercian commented on Sep 18, 2026

   

   cestercian

   on Sep 18, 2026

   Contributor

   More actions

   Looking into this — planning to fix the /btw answer dialog so it renders inside PluginProvider (or otherwise avoids the out-of-context access).

   👍React with 👍1Reacted by Dan Smolsky
3. patrickzxk commented on Sep 18, 2026

   

   patrickzxk

   on Sep 18, 2026

   More actions

   Confirming the same crash on a different environment (macOS), for extra coverage.

   Environment

   • opencode version: 2.0.8
   • OS: macOS 27.0.0 (arm64)
   • Terminal: Ghostty 1.3.1 (TERM=xterm-256color, COLORTERM=truecolor)
   • Shell: /bin/zsh
   • Install/channel: latest release
   • Active plugins: one local plugin (opencode2-quota); the crash occurs in the built-in opencode.btw plugin, not the user plugin

   Reproduction

   1. Open an existing session in the TUI.
   2. Run /btw <question>.
   3. Once the generated answer returns, the TUI shows the crash screen.

   Reproduces every time — not intermittent.

   Actual behavior

   Error: PluginProvider is missing
       at sc (/$bunfs/root/chunk-78sbr86b.js:2593:2804)
       at Qc (/$bunfs/root/chunk-3y6z3143.js:4:248)
       at Xn (/$bunfs/root/chunk-p4ydqyaa.js:2:7348)
       at children (/$bunfs/root/chunk-78sbr86b.js:2590:118420)
       ...
   

   The top frame is at chunk-78sbr86b.js:2593:2804, which matches the offset in #49790 (chunk-vbstx86m.js:2593:2804) — only the build hash differs. So this is the same usePlugin()-outside-PluginProvider path as described here. The root-cause analysis above (PluginProvider mounted beneath DialogProvider, while dialogs render outside the child subtree) is consistent with what we see.
4. kyeshmz commented on Sep 18, 2026

   

   kyeshmz

   on Sep 18, 2026

   More actions

   Confimred with Wezterm as welll on macOs latest and opencode 2.0.8
5. Asura7170 commented on Sep 19, 2026

   

   Asura7170

   on Sep 19, 2026

   More actions

   Same crash on Windows, confirming cross-platform repro: opencode 2.0.8, Windows 10.0.26200 (x64), WarpTerminal. Ran /btw while the agent was still working, TUI crashed with Error: PluginProvider is missing. Stack matches offset-for-offset (chunk-qp8tk0rb.js:2593:2804), only the chunk hash differs by platform, same as #49790.
6. stevoland commented on Sep 19, 2026

   

   stevoland

   on Sep 19, 2026

   ContributorAuthor

   More actions

   Fixed in 2.0.9 thx
7. stevoland

   closed this as completedon Sep 19, 2026
8. brettanthonysjoberg179-lab commented on Sep 27, 2026

   

   brettanthonysjoberg179-lab

   on Sep 27, 2026

   More actions

   One more environment data point, plus a root-cause detail that may be useful for the fix.

   New repro not yet covered here: Linux x64, and zero plugins configured.

   • opencode version: 2.0.8
   • OS: Linux 6.6.141-09476-g954adab60416 (linux x64)
   • Terminal: TERM=xterm-256color, no COLORTERM / TERM_PROGRAM
   • Shell: /bin/bash
   • Install/channel: latest release
   • Active plugins: none — no plugin key in opencode.jsonc, no .opencode/plugin(s)/ directory

   The existing confirmations in this thread (macOS x2, Windows) either had a local plugin installed or didn't state plugin state. This reproduces with an empty plugin configuration, which confirms the failure is entirely independent of user plugins — PluginProvider is internal to opencode.

   The stack matches offset-for-offset (chunk-vbstx86m.js:2593:2804, caller chunk-x0cbprj9.js:4:248), only the chunk hash differing.

   One detail from the bundle that may be relevant to the fix. The accessor is called unconditionally at the top of the /btw dialog component body, not inside a lazy computation:

   // throw site
   function sa(){let t=Xn(ZW);if(!t)throw Error("PluginProvider is missing");return t}
   
   // caller — /btw answer dialog
   function Uc(t){let r=Je(),o=Vt(),i=QH(),u=sa(),l=He("elevated"),m=He("overlay"),...

   Because the read happens during component setup, it throws on render regardless of whether any plugin is installed. There are 11 call sites of this accessor across the TUI bundle, so any of them rendered outside the provider would fail identically — the fix may want to check the full set rather than just the /btw dialog.

   (Confirmed already fixed in 2.0.9 per the closing note — posting only to add the Linux / no-plugin coverage.)