`/resume` not showing the thread name.

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

• #16562
• #16405
• #16280
• #16291

Powered by Codex Action

Check the proposed sessions. Different from cases:

• #16582 describes resume after exiting the session. In my case, I am within the TUI without exit.
• #16291 is a good feature to have. I agree with it.

The other two are internal behavior, not related to my use-visible phenomenon.

I'm not able to repro the problem as described. When I rename a thread, the updated name appears as expected in the resume session picker.

You mentioned that you're using /resume to see all of your sessions, but this command intentionally filters your sessions based on the cwd (i.e. the project directory where you launched the CLI). If you want to resume a session from a different project, you can quit the CLI, then switch to that directory and use codex resume. Does that explain the behavior you're seeing?

@etraut-openai Thanks for your response. I guess I forgot to mention that I forked the session before and renamed it. Thus, I effectively have many sessions based on the cwd (cuz each session serves different purposes, though I am not sure if this is the intended usage) and I was switch among them using /resume. I was expecting that /resume would show different Thread names after I renamed the forked session.

Can you reproduce based on my description? Do you need some other material for better understanding?

I'm not able to repro. Here's what I tried:

1. Launch CLI. Issue a simple prompt ("1+1").
2. Use /fork. Issue a new command ("2+2"). Use /rename to rename this fork something else ("Addition").
3. Use /resume to select the original session. Use /fork. Issue a new command ("3-2"). Use /rename to rename this fork "Subtraction".
4. Use /resume and observe that there are now three resumable sessions including one named "Addition" and another named "Subtraction".

@etraut-openai Thanks for your response. I did the same test. And what I found, a bit strange to me:
I did the same test as you did on my Linux vm server and my macOS. And I just did 1 and 2 as in your steps.

• On my macOS, I saw the correct things. The conversation column showed the changed name (if this is the intended behavior)

<img width="433" height="94" alt="Image" src="https://github.com/user-attachments/assets/f353c07f-855c-482e-8336-62ac0024a76a" />

• On my linux server, I saw the wrong things. The conversation column did not change:

<img width="440" height="110" alt="Image" src="https://github.com/user-attachments/assets/93414c2c-65ce-4a88-9f1d-bcc469ff9953" />

Status seem to be fine in both cases:

• On my macOS:

<img width="563" height="352" alt="Image" src="https://github.com/user-attachments/assets/15ade1fa-da6a-4072-8e7b-e3f953d3595c" />

• On my linux:

<img width="563" height="332" alt="Image" src="https://github.com/user-attachments/assets/7bb1b321-00a5-4d53-b099-6c0cead86290" />

Do you have some ideas where I should check? Or I can do some investigation over what files /rename changes and /resume reads. I suspect it can a permission issue.

Also another bug I encountered is that if you select the current session in /resume, codex will simply exit. Shall I create another issue about this bug?

The bug related to resuming the current session is a known issue and will be fixed in the next release, so no need to log another issue.

If you resume a renamed thread on your Linux machine after quitting and restarting the CLI, does /status show the new name, or does it revert back to the original thread name? I'm guessing that it will revert back, which means that there must be a persistence issue. The thread metadata (including the new name) should be persisted to the file CODEX_HOME/session_index.jsonl. You can look at that file to see if it's being updated after the /rename.

A "fix" that works for me on Ubuntu CLI is to maximize and restore back the terminal window. Win+up, Win+down, thread names are back, problem solved. If it works, it's not stupid!

If you resume a renamed thread on your Linux machine after quitting and restarting the CLI, does /status show the new name, or does it revert back to the original thread name? I'm guessing that it will revert back, which means that there must be a persistence issue.

It did not revert back.

The thread metadata (including the new name) should be persisted to the file CODEX_HOME/session_index.jsonl. You can look at that file to see if it's being updated after the /rename.

It is indeed in CODEX_HOME/session_index.jsonl

@etraut-openai I spent some time to understand the codex arch. On both my ubuntu machine and my macOS desktop, the live local app-server returns the same thing with

      - preview: "1+1=?"
      - name: "addition"

But the ubuntu client picker somehow, which I did not understand why yet, skipped the cache entry insertion and let to a None in

let thread_name = self.thread_name_cache.get(&thread_id).cloned().flatten();

which did not happen on macOS.

The only thing I can hypothesize is that they are not using the same commit for building?

Latest commit

Then on my Ubuntu server, I tested it with the latest commit. The latest commit works well so I guess we just need to wait for the next release then see if we can close this issue.

This is fixed in the newest release. I am closing this issue.

I still have this issue on latest codex cli. So it's not really fixed. OpenAI Codex (v0.144.1)