What issue are you seeing?
If a new session starts by creating a goal with /goal, the thread can still be resumed by id, but it does not show up in the normal session lists.
The session history exists after the goal is created, including normal assistant messages, and the thread can be opened by id. But list-based discovery does not show it.
Observed:
codex resume <thread_id> opens the session.- The resumed session contains the later assistant messages.
codex resume does not list the same session.- Codex Desktop recents for the same workspace also do not show it, even though nearby sessions that started with a normal user message do appear there.
- Sessions in the same workspace that start with a normal user message do show up in Desktop recents and in
codex resume.
- A session that starts with a normal user message and uses
/goal later also shows up.
What steps can reproduce the bug?
-
Start a new Codex session in a workspace.
-
Make the first interaction /goal and create a goal.
-
Let Codex respond with normal assistant messages.
-
Try to resume by id:
This works, and the later assistant messages are present.
-
Try to find it through the picker:
The session is missing.
-
Check Codex Desktop recents for the same workspace.
The session is missing there too, while nearby sessions that began with normal user messages are listed.
Control case: start a new session with a normal text message first, then use /goal later. That session appears normally.
What is the expected behavior?
A valid thread should be listed even when the first interaction is /goal.
If there is no first normal user message, Codex should use the goal objective, the first assistant message, or a fallback title so the thread remains discoverable.
Additional information
Platform observed on:
I searched for existing reports around goal, resume picker, first_user_message, and missing Desktop recents. The closest issues I found were broader session-listing bugs (#14370, #16095, #16515, #18993), but I did not find this specific /goal-first repro.
What issue are you seeing?
If a new session starts by creating a goal with
/goal, the thread can still be resumed by id, but it does not show up in the normal session lists.The session history exists after the goal is created, including normal assistant messages, and the thread can be opened by id. But list-based discovery does not show it.
Observed:
codex resume <thread_id>opens the session.codex resumedoes not list the same session.codex resume./goallater also shows up.What steps can reproduce the bug?
Start a new Codex session in a workspace.
Make the first interaction
/goaland create a goal.Let Codex respond with normal assistant messages.
Try to resume by id:
This works, and the later assistant messages are present.
Try to find it through the picker:
The session is missing.
Check Codex Desktop recents for the same workspace.
The session is missing there too, while nearby sessions that began with normal user messages are listed.
Control case: start a new session with a normal text message first, then use
/goallater. That session appears normally.What is the expected behavior?
A valid thread should be listed even when the first interaction is
/goal.If there is no first normal user message, Codex should use the goal objective, the first assistant message, or a fallback title so the thread remains discoverable.
Additional information
Platform observed on:
I searched for existing reports around
goal,resume picker,first_user_message, and missing Desktop recents. The closest issues I found were broader session-listing bugs (#14370, #16095, #16515, #18993), but I did not find this specific/goal-first repro.