Expose a custom statusline widget API for the CLI airline

Summary

Codex CLI should expose a custom statusline widget API rather than only growing a fixed list of built-in statusline elements.

The current configurable statusline/airline direction is good, but it is still constrained if every new need requires another built-in field. The next step should be a high-performance widget system that can render richer statusline components cleanly.

Motivating example

One concrete widget would be an edited file stack:

• display edited files in order from latest to oldest
• show the last 5 files
• render each file as a compact block/tag
• separate blocks with a lightweight nerd-font / ASCII chevron (>-style) delimiter

This is a strong use of horizontal space because it gives spatial awareness about what the current Codex session is actually touching.

Why a widget API instead of more built-ins

A single custom widget API would subsume many future requests:

• thread/context identity widgets
• edited-file stacks
• richer mode indicators
• animated progress/status affordances
• compact attribution/grouping surfaces

Instead of shipping one-off built-ins forever, Codex could expose a composable statusline surface with a high bar for extensibility.

Requested design direction

• support custom statusline widgets, not just predefined statusline elements
• widgets should receive enough structured session/state input to render useful context cleanly
• widgets should be able to occupy the remaining horizontal space intelligently
• animation support should be possible for richer widgets: scrolling gradients, smooth tag motion along the cell grid, and regular frame/tick updates

Performance / implementation preference

This should ideally be a Rust-native extension surface, not shell-script-based customization.

Reasoning:

• keep Codex’s TUI performance bar extremely high
• avoid encouraging fragile shell-driven rendering loops
• make animation and frequent updates realistic without turning the statusline into a slow sidecar

High bar to entry is fine here if the reward is a clean, fast, powerful widget surface.

Success criteria

• users can define a custom statusline widget without patching Codex itself
• widgets can consume enough structured state to build meaningful layouts like edited-file stacks
• widgets can use horizontal space flexibly rather than being locked to tiny fixed fields
• the API is performant enough for smooth animated/status-rich widgets

Related context

Current element-level statusline requests:

• #12324
• #13660

A widget API would complement those requests and likely reduce future pressure to keep adding one more built-in statusline field.