Atomic can create TUI components. Ask it to build one for your use case.
TUI Components
Extensions and custom tools can render custom TUI components for interactive user interfaces. This page covers the component system and available building blocks. Source: TUI components are provided by Atomic’s installed@earendil-works/pi-tui runtime dependency (node_modules/@earendil-works/pi-tui/dist/).
Component Interface
All components implement:
The TUI appends a full SGR reset and OSC 8 reset at the end of each rendered line. Styles do not carry across lines. If you emit multi-line text with styling, reapply styles per line or use
wrapTextWithAnsi() so styles are preserved for each wrapped line.
Focusable Interface (IME Support)
Components that display a text cursor and need IME (Input Method Editor) support should implement theFocusable interface:
Focusable component has focus, TUI:
- Sets
focused = trueon the component - Scans rendered output for
CURSOR_MARKER(a zero-width APC escape sequence) - Positions the hardware terminal cursor at that location
- Shows the hardware cursor only when
showHardwareCursoris enabled
showHardwareCursor, setShowHardwareCursor(true), or ATOMIC_HARDWARE_CURSOR=1. The Editor and Input built-in components already implement this interface.
Container Components with Embedded Inputs
When a container component (dialog, selector, etc.) contains anInput or Editor child, the container must implement Focusable and propagate the focus state to the child. Otherwise, the hardware cursor won’t be positioned correctly for IME input.
Using Components
Usectx.ui.custom() with a component factory. The factory receives done(result), and ctx.ui.custom() resolves with that result when the component finishes:
{ signal } to ctx.ui.custom() when the UI belongs to an abortable operation. If the signal aborts, Atomic dismisses the custom UI and rejects the returned promise with the signal reason. For overlays, use options.onHandle to receive an overlay handle for programmatic visibility control.
In Atomic’s default interactive mode, the component instance remains in the isolated engine child. The terminal host caches rendered lines and forwards input asynchronously, so render() and handleInput() must not depend on direct access to host process objects. The remote bridge preserves pi-tui’s key-release contract: release events are filtered unless the child component sets wantsKeyRelease = true, matching a directly mounted component. Return values passed to done() must be JSON-safe.
Host terminal modes from an isolated component
Because the component runs in the engine child — whose stdout is the JSONL transport, not a TTY — writing raw terminal escape sequences toprocess.stdout from render()/handleInput() is a no-op and never reaches the real host terminal. For the two host-terminal modes an overlay commonly needs, the factory tui.terminal exposes typed, allowlisted setters that the host applies to the real TTY over the engine protocol:
process.stdout.
Host-native session picker
Remote-rendered components pay one host⇄child round trip per keypress under engine isolation. For session-style list pickers, thectx.ui.hostSessionPicker(request) capability avoids that entirely: the terminal host mounts the real built-in SessionSelectorComponent and feeds it JSON-safe rows, so arrow-key navigation and search stay host-local and survive extension event-loop stalls. Only semantic events cross the host⇄extension boundary: the extension pushes row updates and errors (and may close() the picker); the host reports selection, cancel, and confirmed Ctrl+D deletes.
Every interactive host implements the same API — non-isolated mode mounts the selector directly in-process (no IPC at all), isolated mode routes it over the engine session-picker protocol channel — so callers never branch on the mode. The member is absent only on non-interactive surfaces (headless RPC, print); fail with an actionable error there instead of degrading to a hand-rolled picker.
/workflow resume picker is built exclusively on this channel.
Host-native input form
Usectx.ui.hostInputForm(request) for structured inline forms whose keyboard handling must remain responsive under interactive-engine isolation. The terminal host mounts and focuses the real form in the bottom editor slot (overlay: false); Tab/Shift+Tab, arrows, text editing, configured keybindings, Enter, Escape, and Ctrl+C are handled entirely in the host process. In isolated mode only the JSON-safe open request and the final submit/cancel event cross the engine boundary. Non-isolated mode mounts the same component directly.
string, text, number, integer, boolean, and select. Initial and returned values are raw strings; the caller owns domain coercion. Every current interactive Atomic host exposes the optional capability, while headless RPC and print surfaces omit it. Keep a legacy fallback only when compatibility with older hosts is required.
The bundled /workflow <name> input picker uses this channel and retains its older custom-editor/ctx.ui.custom() paths only as compatibility fallbacks.
Overlays
Overlays render components on top of existing content without clearing the screen. Pass{ overlay: true } to ctx.ui.custom():
overlayOptions:
Overlay Focus
A focused visible overlay keeps input ownership across temporary non-overlay UI. If an overlay opens anotherctx.ui.custom() component without { overlay: true }, that replacement UI receives input while it is active; when it closes, the focused overlay can reclaim input.
Use handle.unfocus() when a visible overlay should stop owning input and let TUI fall back to another visible capturing overlay or the previous focus target. Use handle.unfocus({ target }) when a specific component should receive input while the overlay stays visible. Passing { target: null } intentionally leaves no focused component until focus is set again.
Overlay Lifecycle
Overlay components are disposed when closed. Don’t reuse references - create fresh instances:Built-in Components
Import from@earendil-works/pi-tui:
Text
Multi-line text with word wrapping.Box
Container with padding and background color.Container
Groups child components vertically.Spacer
Empty vertical space.Markdown
Renders markdown with syntax highlighting.Image
Renders images in supported terminals (Kitty, iTerm2, Ghostty, WezTerm, Warp).Keyboard Input
UsematchesKey() for key detection:
Key.* for autocomplete, or string literals):
- Basic keys:
Key.enter,Key.escape,Key.tab,Key.space,Key.backspace,Key.delete,Key.home,Key.end - Arrow keys:
Key.up,Key.down,Key.left,Key.right - With modifiers:
Key.ctrl("c"),Key.shift("tab"),Key.alt("left"),Key.ctrlShift("p") - String format also works:
"enter","ctrl+c","shift+tab","ctrl+shift+p"
Line Width
Critical: Each line fromrender() must not exceed the width parameter.
visibleWidth(str)- Get display width (ignores ANSI codes)truncateToWidth(str, width, ellipsis?)- Truncate with optional ellipsiswrapTextWithAnsi(str, width)- Word wrap preserving ANSI codes
Creating Custom Components
Example: Interactive selectorTheming
Components accept theme objects for styling. InrenderCall/renderResult, use the theme parameter:
theme.fg(color, text)):
Background colors (
theme.bg(color, text)):
selectedBg, userMessageBg, customMessageBg, toolPendingBg, toolSuccessBg, toolErrorBg
For Markdown, use getMarkdownTheme():
Debug logging
SetATOMIC_TUI_WRITE_LOG to capture the raw ANSI stream written to stdout.
@earendil-works/pi-tui dependency.
Performance
Cache rendered output when possible:invalidate() when state changes, then ctx.ui.requestRender() from the extension context or tui.requestRender() from a ctx.ui.custom() factory to trigger re-render.
Invalidation and Theme Changes
When the theme changes, the TUI callsinvalidate() on all components to clear their caches. Components must properly implement invalidate() to ensure theme changes take effect.
The Problem
If a component pre-bakes theme colors into strings (viatheme.fg(), theme.bg(), etc.) and caches them, the cached strings contain ANSI escape codes from the old theme. Simply clearing the render cache isn’t enough if the component stores the themed content separately.
Wrong approach (theme colors won’t update):
The Solution
Components that build content with theme colors must rebuild that content wheninvalidate() is called:
Pattern: Rebuild on Invalidate
For components with complex content:When This Matters
This pattern is needed when:- Pre-baking theme colors - Using
theme.fg()ortheme.bg()to create styled strings stored in child components - Syntax highlighting - Using
highlightCode()which applies theme-based syntax colors - Complex layouts - Building child component trees that embed theme colors
- Using theme callbacks - Passing functions like
(text) => theme.fg("accent", text)that are called during render - Simple containers - Just grouping other components without adding themed content
- Stateless render - Computing themed output fresh in every
render()call (no caching)
Common Patterns
These patterns cover the most common UI needs in extensions. Copy these patterns instead of building from scratch.Pattern 1: Selection Dialog (SelectList)
For letting users pick from a list of options. UseSelectList from @earendil-works/pi-tui with DynamicBorder for framing.
Pattern 2: Async Operation with Cancel (BorderedLoader)
For operations that take time and should be cancellable.BorderedLoader shows a spinner and handles escape to cancel.
Pattern 3: Settings/Toggles (SettingsList)
For toggling multiple settings. UseSettingsList from @earendil-works/pi-tui with getSettingsListTheme().
Pattern 4: Persistent Status Indicator
Show status in the footer that persists across renders. Good for mode indicators.Pattern 4b: Working Indicator Customization
Customize the inline working indicator shown while Atomic is streaming a response.Pattern 5: Widgets Above/Below Editor
Show persistent content above or below the input editor. Good for todo lists, progress.Pattern 6: Custom Footer
Replace the footer.footerData exposes data not otherwise accessible to extensions.
ctx.sessionManager.getBranch() and ctx.model.
Examples: custom-footer.ts
Pattern 7: Custom Editor (vim mode, etc.)
Replace the main input editor with a custom implementation. Useful for modal editing (vim), different keybindings (emacs), or specialized input handling.- Extend
CustomEditor(not baseEditor) to get app keybindings (escape to abort, ctrl+d to exit, model switching, etc.) - Call
super.handleInput(data)for keys you don’t handle - Factory pattern:
setEditorComponentreceives a factory function that getstui,theme, andkeybindings - Pass
undefinedto restore the default editor:ctx.ui.setEditorComponent(undefined)
Key Rules
-
Always use theme from callback - Don’t import theme directly. Use
themefrom thectx.ui.custom((tui, theme, keybindings, done) => ...)callback. -
Always type DynamicBorder color param - Write
(s: string) => theme.fg("accent", s), not(s) => theme.fg("accent", s). -
Call tui.requestRender() after state changes - In
handleInput, calltui.requestRender()after updating state. -
Return the three-method object - Custom components need
{ render, invalidate, handleInput }. -
Use existing components -
SelectList,SettingsList,BorderedLoadercover 90% of cases. Don’t rebuild them.
Examples
- Selection UI: examples/extensions/preset.ts - SelectList with DynamicBorder framing
- Async with cancel: examples/extensions/qna.ts - BorderedLoader for LLM calls
- Settings toggles: examples/extensions/tools.ts - SettingsList for tool enable/disable
- Status indicators: examples/extensions/plan-mode/index.ts - setStatus and setWidget
- Working indicator: examples/extensions/working-indicator.ts - setWorkingIndicator
- Custom footer: examples/extensions/custom-footer.ts - setFooter with stats
- Custom editor: examples/extensions/modal-editor.ts - Vim-like modal editing
- Snake game: examples/extensions/snake.ts - Full game with keyboard input, game loop
- Custom tool rendering: examples/extensions/todo.ts - renderCall and renderResult