Codex App renames conversations to "New task"

Open 💬 2 comments Opened Jul 9, 2026 by RohanAdwankar

What version of the Codex App are you using (From “About Codex” dialog)?

Version 26.707.30751

What subscription do you have?

Enterprise

What platform is your computer?

_No response_

What issue are you seeing?

I see my conversations in the Projects section but whenever I click to open them it changes to "New task" and also doesn't open them. This continue on every conversation I click. May be something to do with how codex cli and codex app are interacting.
However at some point before it used to work well.

What steps can reproduce the bug?

Use codex CLI to create conversations then /app to open them in the app. Also may have something to do with me using /fork a lot.

What is the expected behavior?

Open the conversation shown.

Additional information

_No response_

View original on GitHub ↗

2 Comments

ofek · 1 month ago

After the update that merged ChatGPT, this is what I see:

<img width="534" height="908" alt="Image" src="https://github.com/user-attachments/assets/d7d02ce4-0a9c-427f-b5df-c816ac454831" />

Clicking on a thread seems to restore the name:

<img width="355" height="252" alt="Image" src="https://github.com/user-attachments/assets/a2c77298-34d1-48e6-a934-35d62d74b4c4" />

zyfasos · 1 month ago

I am seeing a very similar symptom on the current ChatGPT-integrated Codex desktop app.

Environment:

  • Platform: macOS / Apple Silicon
  • ChatGPT app: 26.715.31925, build 5551
  • Embedded binary: /Applications/ChatGPT.app/Contents/Resources/codex
  • Embedded CLI version: codex-cli 0.145.0-alpha.18

User-visible symptom:

  • After restarting the desktop app, some historical threads in the left sidebar show as New task / blank-title rows instead of their expected names.
  • The underlying conversation is still present.
  • Clicking/opening the affected thread causes the message history to load and the title/name to appear again.
  • This looks like a sidebar metadata/catalog/title-cache hydration issue rather than data loss.

Local read-only diagnostics from the same machine:

~/.codex/state_5.sqlite threads total: 167
threads.title = '' rows:                 9
threads.preview = '' rows:               9
empty-title rows with rollout file:      9
empty-title rows missing rollout file:   0
empty-title ids present in session_index.jsonl: 0

Relevant local storage observation:

  • Thread/list metadata exists in state_5.sqlite.threads.
  • Thread names are also tracked through session_index.jsonl and the local thread catalog DB.
  • logs_2.sqlite only contains logging rows and has no thread-title fields, so this does not look related to the previous SQLite TRACE logging mitigation.

No raw transcript contents, thread IDs, or local project paths are included here.