›_ Codex Issues
Codex Issues / #14482

Allow setting thread name at session start with codex --name

Open 💬 8 comments Opened Mar 12, 2026 by zipus

What variant of Codex are you using?

CLI

What feature would you like to see?

Summary

Add a --name flag to the interactive CLI so a thread can be named when it is created:

``bash
codex --name "issue AAA"
`
This should work with the existing thread naming and resume behavior, so the same session can later be resumed with:
`bash
codex resume "issue AAA"
``
## Problem

Today, naming a conversation is a two-step flow:

  1. Start a session with codex
  2. Rename it later with /rename

That works, but it is awkward when the intended thread name is already known before starting the session, for
example when opening work for a specific bug, issue, or task.

## Proposed behavior

Support:

codex --name "issue AAA"

Expected behavior:

  • Starts a fresh interactive session
  • Sets the initial thread name to "issue AAA"
  • Persists that name through the existing session index / thread naming path
  • Makes the session resumable via:

codex resume "issue AAA"

## Scope

This request is only for naming a fresh session at startup.

I would not expect --name to implicitly rename resumed or forked sessions. Those cases should probably either:

  • reject --name with a clear error, or
  • be handled in a follow-up design discussion

## Why this shape

codex --name "..." fits the current CLI better than a separate codex name "..." command because naming is metadata
for the normal interactive startup path, not a distinct top-level mode.

This looks like it should be a relatively small change because:

  • /rename already persists thread names
  • codex resume <name> already resolves thread names

So the missing part is mainly exposing an initial-name option on the fresh-session path.

Additional information

_No response_

View original on GitHub ↗

8 Comments

zipus · 4 months ago

I implemented this on my fork, but GitHub is blocking PR creation because openai/codex only allows collaborators
to open pull requests.

Branch:
zipus/issue-14482-initial-thread-name

Commit:
382d8909

Fork branch URL:
https://github.com/zipus/codex/tree/zipus/issue-14482-initial-thread-name

Summary:

  • add codex --name "..." for fresh interactive sessions
  • persist the initial thread name through the existing thread/session naming path
  • reject --name on resume/fork instead of ignoring it
tkozzer · 3 months ago

Now that 0.120.x has /rename in interactive mode, it just makes sense to have a --name flag. Hoping this can get bumped up and gain some traction for next release.

baawhee · 2 months ago

That would be a great addition to the CLI!

NightGlowww · 1 month ago

Adding a related Desktop use case: this would also help Codex Desktop users whose first prompt naturally begins with long local paths.

Example workflow:

/Users/<user>/Desktop/<workspace>/<project>/<document>.docx
Please modify this file according to the attached/spec document...

Today, if that first prompt is used as the initial title or remains as a stale fallback in metadata, Desktop Projects/sidebar rows become very long and hard to scan. A creation-time name such as:

codex --name "Course material revision"

or an equivalent Desktop UI field would avoid relying on the first prompt as title metadata.

Related current behavior I observed on Codex Desktop 26.519.31651 / CLI 0.133.0:

  • the app-server protocol already exposes thread/name/set with { threadId, name }
  • after rename/generation, session_index.jsonl can contain the concise title while state_5.sqlite.threads.title still contains the long first prompt
  • I added more concrete drift/repro details in #16405

So --name / initial-name support would solve the workflow problem, while #16405 tracks keeping the persistence layers in sync after a name is set.

Higor-Matos · 1 month ago

I hit this in daily CLI use with multiple concurrent Codex sessions.

Environment:

  • codex-cli 0.139.0
  • macOS
  • separate wrapper/CODEX_HOME flows for personal and work sessions

Desired workflow:

codex --name "desc-pay refund panel"
codex resume "desc-pay refund panel"

This would avoid the current start-then-rename flow when the intended task name is already known. I am going to try a focused implementation and will link a branch or PR if GitHub allows it.

Higor-Matos · 1 month ago

I implemented a focused branch for this on my fork, but GitHub is blocking PR creation from my account with:

GraphQL: Higor-Matos does not have the correct permissions to execute `CreatePullRequest`

Branch/commit:

Implementation summary:

  • adds codex --name <THREAD_NAME> for fresh interactive sessions
  • normalizes/rejects empty names before TUI startup
  • rejects --name for subcommands and for resume/fork paths instead of silently ignoring it
  • uses the existing thread/name/set app-server API immediately after thread/start, so it works through the current TUI app-server startup path without adding a new thread/start protocol field

Validation:

  • cargo fmt --all (fallback because just is not installed locally)
  • cargo test -p codex-cli name_flag --bin codex
  • cargo test -p codex-tui thread_name --lib

The first test run hit a webrtc-sys GitHub download timeout for webrtc-mac-arm64-release.zip; I pre-downloaded the expected archive into the local Cargo build cache and reran the tests successfully.

est7 · 16 days ago

Friendly ping on this.

There now seem to be multiple independent implementations of this feature, along with several users requesting the same workflow. The implementation also appears relatively self-contained since it builds on the existing thread naming and resume infrastructure.

Is there any maintainer feedback on the proposed --name approach, or any design concerns that should be addressed before this can move forward?

I'd be happy to help test or iterate on the implementation if that would help get it merged.

sshekhar-coursera · 5 days ago

Is this being picked, its a real important feature I am awaiting.