Codex Task Title Organizer — project-aware titles without reading transcripts

[znbsf]

I built Codex Task Title Organizer, a standalone Codex Desktop plugin for people whose task sidebar fills up with similar-looking titles.

The goal is intentionally narrow: make many tasks easier to scan and return to without reading transcripts or modifying Codex databases.

Default color-block style

Titles follow this shape:

Marker Domain｜Project/repository｜Work type｜Concrete object: purpose or symptom

The package combines a skill with a privacy-conscious UserPromptSubmit Hook:

• prompt 2 establishes a useful project-aware title;
• prompt 4 refines it only when clearer context is available;
• prompt 10 refreshes it only after a material change;
• older Codex tasks can be normalized manually in bounded batches of at most 10;
• private projects fall back to the project name, repository name, or cwd basename instead of inventing a placeholder ID.

Color blocks are the default, but the skill also supports semantic icons and an explicit project-defined custom marker or category mapping in AGENTS.md.

Semantic-icon variant

Privacy boundary

The Hook stores only hashed session/turn identifiers, small counters, and fired checkpoints. It does not persist prompt text, generated titles, transcripts, rollout data, Codex databases, full paths, or project taxonomy.

Install

codex plugin marketplace add znbsf/codex-task-title-organizer --ref main
codex plugin add codex-task-title-organizer@codex-task-title-organizer

After installing, restart or refresh Codex, inspect the exact command in /hooks, and explicitly trust it before automatic checkpoints become active. The current package is v0.4.0; its 14 tests pass locally and the latest Windows/Linux CI run is green.

This is an interim workflow rather than a replacement for native title management. It does not add folders, full-text search, task status, or cross-device sync.

Questions for the Codex team and plugin authors

1. Is there a supported extension point for a plugin to expose a native or near-native task action, such as Regenerate title or Apply title format, in the sidebar or task menu?
2. If not, could Codex expose a narrowly scoped title-generation setting, Hook, or API used by the official title generator? For example, a user or project could define Marker｜Project｜Work type｜Summary, while Codex generates the values and always preserves manually edited titles.
3. For people managing 20+ tasks, do color blocks, semantic icons, or a project-defined marker make the sidebar easiest to scan? Are checkpoints 2, 4, 10 useful or too intrusive?

Related native feature requests: #14044 and #40389.

[ooocooc]

I read the current hook and the Codex title-tool implementation. One measurement gap is worth making explicit: fired_thresholds proves that a checkpoint instruction was emitted, not that the title was changed or even that the title tool was called. The current set_thread_title handler returns only the requested threadId and title; it does not return the previous title or a changed flag:

codex/codex-rs/tui/src/dynamic_tools.rs

Lines 784 to 800 in 2b7c279

	"set_thread_title" => {
	let arguments: TitleArguments = parse_arguments(params.arguments)?;
	if arguments.title.trim().is_empty() {
	return Err("title must not be empty".to_string());
	}
	let thread_id = arguments.thread_id.unwrap_or(params.thread_id);
	let title = arguments.title;
	let _: ThreadSetNameResponse =
	request(&handle, |request_id| ClientRequest::ThreadSetName {
	request_id,
	params: ThreadSetNameParams {
	thread_id: thread_id.clone(),
	name: title.clone(),
	},
	})
	.await?;
	Ok(json!({"threadId": thread_id, "title": title}))

A privacy-preserving way to evaluate 2,4,10 would be to add a narrowly matched PostToolUse observer for the title tool, if that dynamic tool is exposed to hooks in the installed build, and persist only: hashed session/turn, checkpoint number, tool-called yes/no, and error yes/no. Do not persist the requested title. Then run a bounded task set and report the intervention rate at checkpoints 2, 4, and 10. Include a manually edited-title case and require zero later title-tool calls unless the task materially changes.

Because the tool result has no previous-value or changed field, label the metric title tool invoked, not title changed. Checkpoint 10 earns its place only if that bounded test shows useful late corrections rather than repeat invocations; otherwise 2,4 is the safer default.

[znbsf]

You're right about that. fired_thresholds only says the checkpoint was emitted. It doesn't tell me whether set_thread_title ran, and it definitely doesn't tell me whether the title changed.

I'm trying a small PostToolUse check for this now. It only keeps the checkpoint and a hashed turn ID — no title text or tool output. I'll call it “title tool completion observed,” not “title changed.” And if there isn't a post event, I won't assume that means an error; there are a few possible reasons for that.

I'll run it through the 2/4/10 cases, including manual title edits and a task that really changes direction. If 10 mostly turns into repeat calls, I'll drop it and keep 2/4. Appreciate the nudge.