tui: lag/hang on Windows Terminal when the session sidebar is visible (2.1.x, OpenTUI 0.6.6) #57676

Summary

On native Windows (Windows Terminal), the v2.1.x TUI becomes laggy and appears to hang at large window sizes, and the trigger is the session sidebar. At the same window size and in the same session, session.sidebar: "auto" (the default, which mounts the sidebar above 120 columns) is laggy, while session.sidebar: "hide" is smooth. The boundary appears to be v2.1.0, the first release that shipped @opentui/* 0.6.6 instead of 0.5.17.

Environment

• opencode version: 2.1.2 (latest, opencode --version)
• OS: Windows 11, Microsoft Windows NT 10.0.26200.0
• Terminal: Windows Terminal 1.24.12741.0 (WT_SESSION set), TERM=xterm-256color, no TERM_PROGRAM
• Shell: PowerShell 7.6.6
• Install/channel: npm global @opencode/cli, latest channel, shared background service
• Active plugins: opencode-cmd-provider, file:///C:/Users/Admin/opencode-navigator (server); C:/Users/Admin/opencode-subagent-monitor (TUI). None of them claim a sidebar.content or sidebar.footer slot.
• Display: 1536x864

Reproduction

1. Use Windows Terminal on native Windows, with the window maximized (well above 120 columns).
2. Keep the default session.sidebar: "auto" and horizontal tabs (tabs.layout: "horizontal").
3. Open a session with a moderate transcript and interact with it, or let the agent stream output.
4. The UI lags and appears to hang; input and streamed output stutter visibly.
5. Set session.sidebar: "hide" (hot reloads) or shrink the window to 120 columns or fewer. The lag disappears immediately at the same width/height in the same session, with no other change.

Expected Behavior

Smooth rendering at any window size with the sidebar visible.

Actual Behavior

Lag tracks the sidebar being mounted, not scroll or resize alone: the UI is unresponsive while the agent streams, and closing the sidebar fixes it without changing session or window height.

Additional Context

Sidebar threshold

packages/tui/src/component/session-frame.tsx:

const wide = createMemo(() => dimensions().width - props.verticalTabsWidth > 120)
const sidebarVisible = createMemo(() => {
  if (data.session.get(props.sessionID)?.parentID) return false
  if (sidebarOpen()) return true
  return (config.data.session?.sidebar ?? "auto") === "auto" && wide()
})

With horizontal tabs, verticalTabsWidth is 0, so the sidebar mounts at 121 columns or more. Shrinking below that produces the "only lags when large" behavior.

Renderer boundary

@opentui/core, @opentui/solid, and @opentui/keymap are pinned in the root workspace catalog:

2.1.0 was the first release on 0.6. OpenTUI 0.6.2 was merged in #55083 on 2026-10-13 and reverted in #55300 on 2026-10-14 before any release shipped it; #55339 re-landed 0.6.5 on 2026-10-19.

Bisect status

Reported from memory: the previous 4-5 releases (roughly 2.0.29 - 2.0.32, all on 0.5.17) were smooth. Not yet re-verified by pinning 2.0.32 in a clean environment; happy to run that if it helps.

Tried

• Disabling the built-in opencode.sidebar.todo slot with "-opencode.sidebar.todo": no change. With only Context, MCP, and footer left in the sidebar, the lag persisted, so the per-token sessionTodos() scan is not the cause.
• Hiding the sidebar: fixes it completely, which is the current workaround.
• Keeping the window at 120 columns or fewer: also fixes it (the sidebar is not mounted).

Not tested

• animations: false (open tui: animated session tabs cause high CPU/GPU use and slow other apps #57462)
• starting with all plugins disabled
• --standalone
• other terminals (WezTerm/conhost)

Related

• tui: Windows TUI lags on mouse-wheel scroll and window resize (regression vs v1; desktop GUI unaffected) #54239: Windows TUI lag on 2.0.26, i.e. before OpenTUI 0.6, closed as a Windows Terminal CJK font-fallback issue.
• tui: animated session tabs cause high CPU/GPU use and slow other apps #57462: animations cause sustained CPU use and terminal output.