What version of the IDE extension are you using?
openai.chatgpt 26.5601.20914
What subscription do you have?
Not provided
Which IDE are you using?
VS Code Insiders
What platform is your computer?
Linux x86_64
What issue are you seeing?
After renaming a forked Codex thread, later forks can still appear to use the old original title, typically the first user prompt from an ancestor thread, rather than the current visible/custom thread name.
This makes fork chains hard to navigate because several related forks can show the same stale title even after the user explicitly renamed intermediate threads.
Local redacted evidence suggests two durable metadata sources can disagree: session_index.jsonl contains the later explicit renamed title, while ~/.codex/state_5.sqlite table threads can still have threads.title set to the original first prompt for the ancestor and multiple forks. Fork/list/title paths may then choose stale SQLite title metadata or fail to propagate the explicit name.
What steps can reproduce the bug?
- Start a Codex thread whose initial prompt becomes the auto title.
- Fork that thread.
- Rename the fork to a short custom title.
- Fork the renamed fork.
- Compare the new fork title/sidebar title with the renamed parent title.
What is the expected behavior?
A fork from a renamed thread should either inherit the current explicit/custom parent thread name with a clear fork disambiguator, generate a fresh distinguishable title, or at minimum avoid falling back to the stale first-prompt title when an explicit renamed title exists.
Additional information
This seems related but not identical to:
Current public app-server tests appear to assert that thread/fork returns name: null for forked threads. That may be intentional, but it means a fork from a renamed thread has no explicit name to carry forward and can fall back to stale title/preview metadata.
What version of the IDE extension are you using?
openai.chatgpt 26.5601.20914
What subscription do you have?
Not provided
Which IDE are you using?
VS Code Insiders
What platform is your computer?
Linux x86_64
What issue are you seeing?
After renaming a forked Codex thread, later forks can still appear to use the old original title, typically the first user prompt from an ancestor thread, rather than the current visible/custom thread name.
This makes fork chains hard to navigate because several related forks can show the same stale title even after the user explicitly renamed intermediate threads.
Local redacted evidence suggests two durable metadata sources can disagree:
session_index.jsonlcontains the later explicit renamed title, while~/.codex/state_5.sqlitetablethreadscan still havethreads.titleset to the original first prompt for the ancestor and multiple forks. Fork/list/title paths may then choose stale SQLite title metadata or fail to propagate the explicit name.What steps can reproduce the bug?
What is the expected behavior?
A fork from a renamed thread should either inherit the current explicit/custom parent thread name with a clear fork disambiguator, generate a fresh distinguishable title, or at minimum avoid falling back to the stale first-prompt title when an explicit renamed title exists.
Additional information
This seems related but not identical to:
Current public app-server tests appear to assert that
thread/forkreturnsname: nullfor forked threads. That may be intentional, but it means a fork from a renamed thread has no explicit name to carry forward and can fall back to stale title/preview metadata.