Add status-line items for git commit SHA and upstream ahead/behind

Original Request

Can I config my codex statusline to show thing slike current commit hash, ahead/behind origiin, etc Can you add them?

Agent's Two Cents (could be wrong)

Everything below is the AI agent's best guess based on the current codebase. Take with a grain of salt — the original request above is the only thing that came from a human.

Problem / Motivation

Codex CLI's TUI status line has useful built-in git segments such as git-branch, branch-changes, and pull-request-number, but it does not expose the exact checked-out commit or upstream divergence. When working across multiple worktrees or long-running branches, branch name alone is not enough to identify the current checkout state.

Proposed Solution

Add built-in status-line items for compact git repository state:

• git-commit or git-sha: short HEAD SHA, e.g. 58573da
• git-ahead-behind: upstream divergence, e.g. origin/main ↑2 ↓1
• optionally git-dirty: dirty working tree indicator, if maintainers want that separated from ahead/behind

Suggested behavior: use @{upstream} when configured, fall back to origin/<branch> when available, omit the segment when unavailable, and refresh on the same lifecycle as existing git status-line segments.

Dependencies & Potential Blockers

No major blockers identified. The main design choice is whether these should be separate segments or folded into an expanded git summary segment.

How to Validate

• Configure [tui].status_line = ["git-branch", "git-sha", "git-ahead-behind"].
• In a normal repo, verify the status line shows the current branch, short HEAD SHA, and upstream divergence.
• In a detached HEAD repo, verify git-sha still renders while branch/upstream-only segments omit themselves gracefully.
• In a repo without an upstream, verify git-ahead-behind is omitted or shows a clear no-upstream state.
• In linked worktrees, verify the values are computed relative to the active worktree.
• Confirm status-line rendering does not block the TUI on large repositories.

Scope Estimate

medium

Key Files/Modules Likely Involved

• codex-rs/tui/src/bottom_pane/status_line_setup.rs
• codex-rs/tui/src/chatwidget/status_surfaces.rs
• codex-rs/tui/src/bottom_pane/status_surface_preview.rs
• git helper module used by existing git-branch / git summary lookups

Architecture Diagram

config.toml [tui.status_line]
        |
        v
StatusLineItem parser / picker
        |
        v
ChatWidget status surface refresh
        |
        v
async git metadata lookup
        |
        v
cached status-line git state
        |
        v
footer status-line renderer

Rough Implementation Sketch

• Add new StatusLineItem variants and descriptions for SHA and ahead/behind.
• Add async git helper(s) for short HEAD SHA and upstream divergence with bounded timeout behavior matching existing git lookups.
• Cache the computed git metadata by cwd and refresh it with existing git status-line events.
• Add preview placeholder values so /statusline or the picker can show the new items clearly.
• Add tests for normal branch, detached HEAD, no upstream, and invalid/unavailable git metadata.

Open Questions

• Should upstream divergence use @{upstream} only, or fall back to origin/<branch>?
• Should dirty working tree state be included in git-ahead-behind or exposed as a separate git-dirty item?
• Should the commit segment show 7, 8, or config-driven short SHA length?

Potential Risks or Gotchas

• Running multiple git commands during frequent TUI refreshes could hurt responsiveness in very large repos unless cached and refreshed deliberately.
• Worktrees and detached HEAD states need explicit handling so segments omit themselves cleanly instead of showing misleading data.

Related Issues

• #17827: Customizable status line — broader status-line customization request.
• #20043: Support external command-based status line with ANSI colors, similar to Claude Code — related command-hook approach, now closed.

Suggested Labels / Priority

Suggested labels: enhancement, TUI, CLI, Git, NoNewDependencies, AgentsCanDo, AgentsValidatable

Suggested priority: p2