Add Codex CLI statusline support

[ropdias]

Summary

Codex now has a native TUI status line, but the public configuration surface does not currently look equivalent to Claude Code's statusLine command hook. Tokenline can likely support Codex once Codex exposes either a command-backed status-line item or a stable per-refresh/session telemetry payload that tokenline.sh can parse.

As of 2026-09-22, official OpenAI Docs show:

• tui.status_line in ~/.codex/config.toml / .codex/config.toml is an ordered array of status-line item identifiers, or null/empty to disable/hide it: https://developers.openai.com/pt-BR/docs/config-file/config-reference
• The sample config shows built-in examples like ["model", "context-remaining", "git-branch"] and defaults such as model/context/current directory: https://developers.openai.com/ja-JP/docs/config-file/config-sample
• The current config schema defines tui.status_line as array<string> and describes it as selecting status-line item identifiers, not commands or executable providers: https://developers.openai.com/codex/config-schema.json
• Codex hooks exist, but they are lifecycle events, not a once-per-second statusline renderer. Their transcript_path is documented as convenient but not a stable hook interface: https://developers.openai.com/pt-BR/docs/hooks

So: possible in principle, but not yet wire-compatible with tokenline's current Claude/Antigravity integration path.

Why this matters

tokenline.sh expects the host CLI to pipe a JSON snapshot to stdin every refresh. That snapshot currently includes fields such as model display name, context-window usage, cache read/write tokens, rate-limit reset data, transcript path, and session id. Codex's documented status line config lets users select Codex-owned items; it does not document an external command item that can pass equivalent live telemetry to a script.

Proposed plan

1. Track Codex native support surface

   • Confirm whether any undocumented or upcoming tui.status_line custom item API exists.
   • Check the open-source openai/codex implementation for status-line item registration and whether custom commands can be added cleanly.

2. Define the minimum Codex telemetry contract tokenline needs

   • model / reasoning label
   • context used and context window size
   • current-turn input, output, cache read, and cache write token counts if exposed
   • session id
   • transcript path or stable session event source
   • rate-limit percentage/reset data if Codex exposes it

3. Pick an integration route

   • Preferred: Codex supports a command-backed status-line item, e.g. a configured command receiving session JSON on stdin at the TUI refresh cadence. Then add installer support for ~/.codex/config.toml / .codex/config.toml and keep tokenline.sh as the single per-refresh renderer.
   • Upstream route: contribute/request a custom status-line provider to openai/codex if no command item exists.
   • Fallback route: provide a separate watch/tmux style renderer from Codex transcript/log data, similar to the Devin fallback, but mark it as non-native because it would not live in Codex's footer.

4. Implement only after the host surface is stable

   • Add Codex detection/parsing in tokenline.sh without adding new hard dependencies.
   • Extend the npm installer with a Codex target while preserving Claude Code as the default.
   • Update install.sh, README, doctor/uninstall behavior, and tests.
   • Keep failure behavior graceful: malformed/missing Codex telemetry must render a short hint or nothing and exit 0.

Open questions

• Does Codex intentionally support third-party/custom status-line identifiers, or are IDs limited to built-ins?
• Can Codex expose cache economics and rate-limit reset data to local UI extensions?
• Is the status line refresh cadence tied to TUI rendering only, or can a command item be refreshed independently like Claude Code's refreshInterval?

Acceptance criteria

• A documented Codex setup path exists in the README.
• tokenline.sh can render Codex data without Node in the hot path.
• Installer changes are idempotent, backup config before edits, and never clobber invalid TOML/JSON.
• ShellCheck, lint, typecheck, tests, and build pass.
• If native Codex footer integration is not possible, the issue closes with a documented fallback/unsupported decision rather than pretending parity exists.