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
{{ message }}
Repository navigation
feat(tui/theme): Add UI theme presets (Claude and Codex) to customize TUI arrangement and aesthetics #633
Proposal: UI Theme Presets (Claude and Codex) for Zero TUI
Currently, Zero’s Terminal User Interface (TUI) has a single, fixed layout structure and design style. Introducing user-configurable UI Theme Presets would allow developers to customize the visual alignment, structural arrangement, and overall styling of the TUI depending on their preferences.
This issue proposes planning and designing two initial presets: Claude Theme and Codex Theme.
🎨 Theme Concepts
1. 🧡 Claude Theme (Focused, Minimalistic, Card-Based)
Dense layout with tight padding for maximum information visibility per screen.
Bottom status bar showing real-time CPU, token usage, lock status, and active daemons.
A grid of keyboard shortcut legends always visible at the bottom.
🏗️ Technical Architecture & Implementation Steps
To support dynamically swappable layouts, we need to decouple our BubbleTea rendering from hardcoded dimensions and arrangements in internal/tui/:
Introduce a Theme Spec & Config:
Add a theme field in config.json (values: "default", "claude", "codex").
Define a tui/theme package with layout configuration specs (e.g. padding widths, split-ratios, colors, borders).
Abstract TUI View Layout:
Refactor the main TUI render loop (internal/tui/model.go) to defer view composition (splitting panels, adding borders, headers) to a layout helper that respects the active theme config.
Use lipgloss styles dynamically loaded from the selected theme preset.
Implement Layout Arrangements:
Claude Layout: Single-column padded view with a toggleable side panel.
Codex Layout: Horizontal/vertical split views using lipgloss.JoinHorizontal/lipgloss.JoinVertical.
💡 Discussion / Open Questions
How should we handle themes in light vs. dark terminal backgrounds? Should themes define adaptive palettes?
Should theme configuration allow custom keybindings to match the theme's aesthetic (e.g., Codex using vim-like keys by default)?
Sorry for the delay. Layout presets are a reasonable idea and the TUI is fixed today, so the underlying want makes sense.
Two things worth settling before code. Presets that change structural arrangement, rather than just colours, will touch a lot of rendering paths and are awkward to keep stable as the TUI evolves, so scope matters: colours and spacing are much cheaper than layout. And naming presets after other tools invites comparison in a way that may not be what we want long term, so the naming deserves a maintainer opinion of its own.
@kevincodex1 for a direction call. If the answer is yes, I would suggest starting with colours and spacing only and leaving structural layout out of the first pass.
Escalating rather than approving, @kevincodex1 your call on scope.
Colour themes already exist and are documented in docs/THEMES.md, and #713 adds more. This proposal is broader: it asks for configurable layout and structural arrangement, presets modelled on other tools' interfaces.
That is a different commitment from a palette. Layout presets mean every future TUI change has to work in each arrangement, which is a standing cost on all subsequent TUI work rather than a one-off feature. It may well be worth paying, but the person who will carry that cost should decide.
If the appetite is smaller than the proposal, the useful subset is probably more theme presets within the existing layout, which is cheap and additive.
Activity
Vasanthdev2004 commentedon Jul 29, 2026
Sorry for the delay. Layout presets are a reasonable idea and the TUI is fixed today, so the underlying want makes sense.
Two things worth settling before code. Presets that change structural arrangement, rather than just colours, will touch a lot of rendering paths and are awkward to keep stable as the TUI evolves, so scope matters: colours and spacing are much cheaper than layout. And naming presets after other tools invites comparison in a way that may not be what we want long term, so the naming deserves a maintainer opinion of its own.
@kevincodex1 for a direction call. If the answer is yes, I would suggest starting with colours and spacing only and leaving structural layout out of the first pass.
Vasanthdev2004 commentedon Aug 12, 2026
Escalating rather than approving, @kevincodex1 your call on scope.
Colour themes already exist and are documented in
docs/THEMES.md, and #713 adds more. This proposal is broader: it asks for configurable layout and structural arrangement, presets modelled on other tools' interfaces.That is a different commitment from a palette. Layout presets mean every future TUI change has to work in each arrangement, which is a standing cost on all subsequent TUI work rather than a one-off feature. It may well be worth paying, but the person who will carry that cost should decide.
If the appetite is smaller than the proposal, the useful subset is probably more theme presets within the existing layout, which is cheap and additive.
anandh8x commentedon Aug 29, 2026