Repository navigation
TUI: unreadable mouse text selection in light mode (default opencode theme) #41281
Description
Summary
In light mode, mouse text selection (drag / copy-on-select) becomes unreadable: selected text renders as a near black-on-black block. Dark mode selection looks fine. This reproduces on the default opencode theme and likely any built-in theme whose light-mode text is a dark color, because the TUI theme model does not define mouse selection foreground/background and OpenTUI falls back to inverting colors.
Acceptance criteria
- With theme
opencode(default) and light mode, dragging to select chat/output text keeps readable contrast (clear fg and bg) - Copy-on-select still works (selection copies; toast/behavior unchanged)
- Dark mode selection remains readable (no regression)
- Themes without explicit selection colors get a luminance-aware fallback (or shared default selection colors), not invert-only on light text
- Optional but preferred: theme schema/docs allow explicit mouse selection colors (distinct from
selectedListItemTextused by list UI)
Scope
- Files/routes:
packages/tui/src/theme/index.ts(Themetype / resolve),packages/tui/src/theme/assets/opencode.json(and shared fallback),packages/tui/src/context/theme.tsx/ renderer wiring, OpenTUI selection color application as needed - Repos:
anomalyco/opencode(TUI) - Out of scope: Desktop/web chrome; adding new themes to the picker; WARO product work; OpenCode V2 config migration; unrelated theme polish
Code notes (local repro research)
- Default active theme:
config.theme ?? kv.get("theme", "opencode")inpackages/tui/src/context/theme.tsx ThemeexposesselectedListItemTextfor list/dialog chrome, not mouse drag selection colors- Invert fallback works for dark (light text) and fails for light (dark text), e.g.
opencodelighttext#1a1a1aon#ffffff - Related: Text selection has poor contrast/readability on light terminals with certain themes #5295, Unreadable selected text selection in light themes #12861
WR sizing decision
| Dimension | Points | Max | Notes |
|---|---|---|---|
| Duration | 0 | 25 | TUI bugfix, ≤1–2 days |
| PR scope | 5 | 25 | 1 PR: selection colors + wire to OpenTUI |
| Surface | 0 | 20 | packages/tui theme/renderer |
| Repos | 0 | 15 | OpenCode only |
| Shippability | 0 | 15 | Independent |
| Parallelism | 0 | 5 | Single track |
| Total | 5 | 100 |
Verdict: SINGLE_ISSUE
Workflow
Local clone: /Users/saifer/Documents/WEBS/opencode (dev).
Implement on a fork branch → PR into anomalyco/opencode. Prefer fixing selection colors at theme/renderer level (at least for default opencode light), not recommending users switch themes.
LLM contract
Implementation plan can live in .wr/<issue>.yaml on the PR branch if used locally; GitHub issue body is the source of truth for AC.
Activity
github-actions commentedon Aug 8, 2026
This issue does not follow our contributing guidelines.
What needs to be fixed:
Please edit this issue to address the above within 2 hours, or it will be automatically closed.
This issue might be a duplicate of existing issues. Please check:
If you believe this was flagged incorrectly, please let a maintainer know.
uno0uno commentedon Aug 8, 2026
Summary
selectionBg/selectionFg) so light mode no longer relies on OpenTUI invert (black-on-black)How it was validated
packages/tuitheme tests → 10 pass (incl. light/dark selection contrast)packages/tuitsgo --noEmit→ passPR
(see linked pull request)
Posted by Saifer.
github-actions commentedon Aug 8, 2026
This issue has been automatically closed because it was not updated to meet our contributing guidelines within the 2-hour window.
Feel free to open a new issue that follows our issue templates.