Auto-generate and apply a concise thread name after the first prompt

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #24060

Powered by Codex Action

I tried a local workaround for this in the CLI/TUI flow.

Current workaround:

• A Stop hook runs at low frequency.
• It calls codex exec --ephemeral --disable hooks to generate a concise title from the current transcript.
• It appends a thread_name record to ~/.codex/session_index.jsonl.
• It also copies /rename <title> to the clipboard so the current TUI can be refreshed manually if needed.

This works for persisted history/resume, but it does not update the active TUI statusline unless /rename is executed interactively. So it is only a workaround, not a real solution.

A few guardrails were needed to make it usable:

• cooldown between evaluations,
• minimum user-turn threshold,
• do not overwrite a title that appears to have been manually set,
• hook failures must not block the main session.

The missing official capability seems to be one of:

• a supported session/thread rename API or CLI command,
• a hook output field that can request a session title update,
• or a session update event that refreshes both the persisted index and the active TUI.

I also added local structured logging around the workaround to track skip reasons, rename success, cooldown behavior, latency, and errors. That helps tune the heuristic, but the core limitation is still that hooks cannot currently update the active TUI title.

Adding another data point in support of this.

Environment:

• codex-cli 0.142.4
• WSL / Windows Terminal workflow
• terminal title configured with thread-title

Observed behavior:

• The thread/session has a UUID, e.g. 019f1eac-3bd3-7501-a3bb-85de8f25e2de.
• state_5.sqlite.threads.title is populated, but it is just the full first user prompt:

“so i am using codex cli and i wonder if codex will auto set a title...”

• That makes the resume picker and terminal tab difficult to scan.
• /title only configures which title fields appear in the terminal title; it does not rename or summarize the thread.
• I do not see a documented CLI/slash-command path in this version for setting a concise generated title.

Desired behavior:

• After the first prompt, Codex should generate a short readable title like Codex CLI Terminal Thread Titles.
• It should not overwrite a manually renamed title.
• The generated title should update the active TUI/terminal title and the persisted thread metadata used by codex resume.
• A manual fallback such as /rename <title> or codex rename <session> <title> would also help, but the ideal default is automatic concise naming.

+1

Codex should do this by default. Thread naming is too manual right now for something that has a big impact on everyday usability.

There is already rename plumbing, so this feels like a missing product behavior more than a missing capability. The obvious implementation, if it fits the current architecture, would be to route /rename with no explicit title through a very small model that generates a short thread name, then persist it through the existing rename path. If that is not the exact internal shape, the product behavior should still be the same.

• After the first real prompt, generate a short, useful thread title automatically.
• Make this the default behavior for new threads.
• Reuse the existing rename/title persistence path.
• Never override a title the user set manually.
• Skip naming if the opening prompt is too vague.
• Avoid constant retitling after every few turns.

The current behavior creates unnecessary friction. Once you build up a real session history, weak titles or manual cleanup make resume/history navigation noticeably worse. This is a small UX issue that compounds quickly.

I would treat this as baseline behavior, not a nice-to-have. Other related features are useful, but secondary:

• Natural-language rename when explicitly asked.
• codex --name at startup.
• Dynamic retitling later if the task changes.

The main win is simpler than all of those: a new thread should usually get a good title automatically, by default, without the user having to think about it.

Confirmed with codex-cli 0.144.5 in the VS Code integrated terminal.

My terminal title includes thread-title, but after the first prompt completes it continues to display the thread UUID until I explicitly run /rename. Manual rename updates the terminal title correctly.

Automatically generating a concise title after the first meaningful prompt—while preserving manually assigned titles—would make multiple Codex terminal sessions substantially easier to identify.

Confirmed on codex-cli 0.146.0 on macOS with the VS Code integrated terminal.

Configuration:

[tui]
terminal_title = ["spinner", "thread-title"]

Observed behavior:

• After the first meaningful prompt, state_5.sqlite already contains a human-readable value in threads.title.
• The active TUI still has no thread_name, so the configured thread-title segment continues to display the thread UUID.
• Running /rename <name> updates the terminal title immediately, confirming that terminal-title rendering itself is working.
• A separate app-server thread/name/set call can persist a name, but it does not reliably refresh an already-running TUI owned by another app-server process.

The 0.146.0 TUI source reflects this distinction: StatusLineItem::ThreadTitle reads thread_name and explicitly falls back to thread_id when the name is absent:
https://github.com/openai/codex/blob/rust-v0.146.0/codex-rs/tui/src/chatwidget/status_surfaces.rs#L739-L750

This means the generated/persisted thread title and the user-facing thread name are separate values, and the generated title is not promoted into the name path used by thread-title.

Expected behavior: after the first meaningful prompt, Codex should apply the generated concise title through the normal thread-name persistence and notification path, unless the user has already assigned a name manually. This should update both the active TUI terminal title and future resume/history surfaces.

Current main has changed the timing constraint discussed in this thread in a way that may simplify an implementation.

• #38413 and #38819 added metadata updates without materializing a thread and metadata staging for reserved thread IDs.
• The current TUI regression test starts a fresh session with initial_user_message: None, sends thread/name/set, and verifies the persisted name through thread/read (source at c6058cc).

This means the ordering failure in #31158 accurately describes 0.142.5, but waiting for the first turn is no longer required on current main merely to make name persistence possible. turn/completed could still be a useful scheduling boundary to keep title generation off the primary turn's critical path and avoid competing for provider capacity.

There are two remaining race/UI concerns in the current interfaces:

1. ThreadSetNameParams contains only threadId and name, and ThreadNameUpdatedNotification carries no source or generation token (protocol, notification). A late title-generation result could therefore overwrite a manual /rename unless the apply step is conditional or the persisted metadata records provenance.
2. The TUI currently treats every thread/name/updated as a manual rename and inserts a confirmation history cell (source). Reusing that notification unchanged for automatic naming would add visible history noise.

A robust implementation shape would be:

1. Record eligibility after the first meaningful user message is durably appended.
2. Dispatch a bounded, deduplicated title job after the primary turn becomes idle; timeout, rate-limit, or shutdown must not fail the turn.
3. Apply the result atomically only if no explicit user name has won in the meantime. This could be provenance on name, or separate generated-title metadata with display precedence explicit name > generated title > preview > UUID.
4. Persist through ThreadManager / ThreadStore::update_thread_metadata, which is the documented metadata ownership boundary (source).
5. Emit a transport-neutral JSON-RPC metadata/title notification with a generated origin so the active TUI refreshes silently. The persisted value remains authoritative if a notification is missed.

The two acceptance cases that seem most important are: a concurrent manual /rename always wins, and the generated title refreshes the active TUI without inserting a manual-rename confirmation cell.