feat(tui/theme): Add UI theme presets (Claude and Codex) to customize TUI arrangement and aesthetics

[euxaristia]

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)

• Design Language: Sleek, warm, high-contrast, card-based interface (inspired by Claude.ai's chat UI).
• Color Palette: Cream/soft amber highlights, subtle gray backgrounds, dark mode with deep bronze/charcoal undertones.
• Layout & Arrangement:
  • Centrally aligned chat container with generous padding.
  • Clean separated "cards" for system messages and model responses.
  • Right-aligned sidebar for active tasks, metadata, and token usage, designed as a collapsable drawer.
  • Simplified single-line input bar with a floating appearance.

2. 💚 Codex Theme (Dense, Technical, Matrix-Like)

• Design Language: Technical, high-density, monospace-centric (inspired by a classic terminal IDE / hacker HUD).
• Color Palette: Neon greens, cyan highlights, deep terminal blacks, and vibrant matrix/cyberpunk accents.
• Layout & Arrangement:
  • Side-by-side split screen (Left: chat timeline / Right: real-time terminal command execution output and shell state).
  • 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/:

1. 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).
2. 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.
3. 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)?

[Vasanthdev2004]

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]

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]

Zero supports palette selection through the existing theme system, but structural layout presets are not planned. Closing this request for now.