Expose the full thread title to hook payloads (the terminal title truncates it to 48 chars)
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 125k
- Forks
- 19.5k
- PR merge metrics
- PR metrics pending
Description
What variant of Codex are you using?
CLI (v0.154.0), running inside tmux, under Windows Terminal / WSL2.
What feature would you like to see?
A supported way for an external consumer - a tmux window list, a shell prompt, a status line - to read the full thread title, instead of the truncated copy that is written to the terminal title.
Either of these would be enough:
- Add the thread name to the hook payload, for example a
thread_namefield alongside thesession_id,transcript_path,cwd,modelandpermission_modefields that are already there. Hooks run in the session's environment and can already identify the thread, so they are the natural place for it, with no new mechanism to invent. - Or make the terminal title's per-item length cap configurable, so the title itself can carry the whole name.
Additional information
The truncation happens before the name reaches the terminal, so no consumer can undo it. truncate_terminal_title_part in codex-rs/tui/src/chatwidget/status_surfaces.rs is called with 48 for the thread name (45 graphemes + ...), while the other items get 32 and the project name 24; the whole title is then capped at MAX_TERMINAL_TITLE_CHARS (240) in tui/src/terminal_title.rs. tui.terminal_title only chooses which items appear, so there is no length knob, and switching thread-title for thread-name does not help either - both resolve to the same thread_name.
A fixed budget is reasonable for a title. The problem is that this value is also the only signal a terminal multiplexer can read: tmux exposes the pane title as #{pane_title}, which lets a window list show what each pane is working on for free. With a 48 character cap, a title like
split the nightly export into smaller incremental jobs (54 chars)
arrives as split the nightly export into smaller increme... and the tail is simply gone.
The full name does exist locally: $CODEX_HOME/state_5.sqlite keeps it intact in threads.name (mine holds names up to 104 characters, and none of them end in ...). The only way to reach it from outside today is to open that SQLite database read-only from a hook and match threads.id against the payload's session_id. That works, but it is reading Codex's private state from an unsupported angle, so it can break without warning - a hook payload field would turn the same thing into a supported one.
I asked for this from a tmux window list, but it applies to any external consumer: session managers, prompt themes, notification scripts.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start in codex-rs/tui/src/chatwidget/status_surfaces.rs, where the thread name is truncated, and read tui/src/terminal_title.rs to understand the overall title cap and item selection. Trace the existing hook payload fields and determine which requested path is appropriate; done means an external consumer can access the full thread name through a supported mechanism without relying on SQLite state.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- cli
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Clearly specified
- Newbie friendliness
- 55/100