Chat titles should be auto-updated as the conversation steers along

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

• #23203

Powered by Codex Action

We have been testing a project-level workaround in Codex Desktop that suggests a useful native policy for this feature.

In a multi-session project, our AGENTS.md asks each new session to:

1. Wait for the first concrete task instead of naming from a greeting or vague opening prompt.
2. Use the existing codex_app__set_thread_title capability to apply a concise title.
3. Prefer a stable structure such as <project or domain> | <specific deliverable>, which makes the sidebar easy to scan and naturally groups related work.
4. Rename again only when the task boundary materially changes. Additional constraints, implementation details, or ordinary follow-ups should not trigger another rename.
5. Treat a user-specified/manual title as authoritative and never overwrite it.

This instruction-level workaround works well because the active agent already has the semantic context needed to distinguish “the task is now clear” from “another message arrived.” It also demonstrates why this should be a native Codex behavior rather than something every repository has to reproduce in AGENTS.md.

A robust native policy could therefore combine this issue with #24289:

• auto-name after the first meaningful task becomes clear;
• evaluate later changes at low frequency and on semantic task-boundary changes, not simply after N turns;
• preserve a stable project/domain prefix where project context is available;
• avoid generic titles copied from the first prompt;
• manual rename always wins (or locks automatic updates);
• title-generation failure must never block the main task.

The key product distinction is between rename plumbing and title lifecycle policy. Codex already exposes enough plumbing for an agent-driven workaround; the missing piece is making that lifecycle policy a consistent default across sessions and projects.

I have the same problem and built a small local proof of concept: https://github.com/Deep-Octopus/codex-latest-task-title

Why this is needed

A Codex thread often changes direction as the work progresses. The sidebar title, however, usually stays tied to the first prompt. That creates a simple but recurring problem:

• the title describes how the work started, not what the thread is doing now;
• several long-running threads become hard to tell apart;
• finding the right thread later takes more time;
• manual rename works, but users must remember to repeat it in every thread.

For example, a thread may start with “help me inspect this repository” and later become “fix Windows authentication retries”. Keeping the first title makes the sidebar misleading.

Why the plugin workaround is not enough

The proof-of-concept plugin updates the title from the latest concrete request and stops after a manual rename. It works, but it has to reconstruct information that Codex already owns:

• hook input does not say whether the current title was automatic or manual;
• the workaround needs local state to remember its last automatic title;
• it must read local thread metadata to detect a manual change;
• every user has to install and trust the same workaround;
• unsupported clients cannot get the same behavior.

This is lifecycle behavior for a Codex thread, so it is more reliable and consistent as a native feature.

What current source suggests

On current main, thread metadata already separates:

• title: a best-effort title derived from history;
• name: an explicit user-facing name.

The current metadata extraction/sync path only fills the derived title when it is empty, which explains why the first useful prompt remains authoritative forever.

That existing distinction provides a clean rule: automatic updates may change the derived title, but an explicit user name must always win.

Proposed native behavior

1. Generate an automatic title after the first concrete task is clear.
2. Re-evaluate only when the task meaningfully changes, not after every small follow-up.
3. Never update automatically when an explicit/manual name exists.
4. Keep titles short, safe, and in the user’s language.
5. Make title generation best-effort and asynchronous so failure never blocks the main task.
6. Persist the automatic title and notify clients through the existing thread metadata/name update path.
7. Cover at least these cases:

• a vague opening followed by a concrete task;
• a real task-boundary change;
• “continue” or an added constraint that should not rename;
• a manual rename that permanently stops automatic updates;
• title-generation failure that leaves the turn unaffected.

This would address #24060 while staying compatible with the manual-title requirement in #24289 and the broader request in #23203.

I reviewed the repository contribution policy and will not open an unsolicited code PR. Could a maintainer confirm whether this lifecycle policy matches the intended direction and, if so, invite a focused implementation PR?