Issue Station
Sign In
Tools hereToolbox

codex - ✅(Solved) Fix /goal-first sessions are missing from resume lists [1 pull requests, 6 comments, 3 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openai/codex#20792•Fetched 2026-05-03 04:45:21
View on GitHub
Comments
6
Participants
3
Timeline
15
Reactions
0
Author
pauloportellapauloportella
Participants
etraut-openaietraut-openaigithub-actions[bot]github-actions[bot]pauloportellapauloportella
Timeline (top)
commented ×6labeled ×5unlabeled ×3cross-referenced ×1

Fix Action

Fixed

PR fix notes

PR #20800: Show /goal-started threads in resume picker

Description (problem / solution / changelog)

Addresses #20792

Why

Starting a new thread with /goal <objective> creates goal state, but it can happen before the lazily-created thread has a rollout file or first user message. The resume picker relies on the existing thread listing/preview path, so these goal-started threads were invisible until the user first sent a normal prompt.

What changed

  • Materialize the running lazy thread before setting a new goal objective, so the rollout exists on disk for resume discovery.
  • If the thread does not already have a first user message, append and flush a /goal <objective> user message so existing preview/listing logic can surface the thread.
  • Leave threads that already have user history unchanged.

Alternative considered

Another viable fix would be to treat goals as resumable metadata in the listing stack: include thread_goals rows whose threads.first_user_message is empty, merge those metadata-only rows through codex-rollout and codex-thread-store, and derive the resume preview from the goal objective.

That keeps the goal command out of rollout history, but it couples goal state into the core list/read pagination paths and requires new preview hydration logic outside the goal feature. This PR keeps the existing resume contract instead: a resumable thread has a materialized rollout and a first-user-message preview. The extra work is localized to thread/goal/set and only runs when a goal objective is set on a running thread.

Changed files

  • codex-rs/app-server/src/codex_message_processor.rs (modified, +2/-0)
  • codex-rs/app-server/src/codex_message_processor/thread_goal_handlers.rs (modified, +64/-0)
  • codex-rs/app-server/tests/suite/v2/thread_list.rs (modified, +77/-0)

Code Example

codex resume <thread_id>

---

codex resume

---

Darwin 25.5.0 arm64 arm
RAW_BUFFERClick to expand / collapse

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?

  1. Start a new Codex session in a workspace.

  2. Make the first interaction /goal and create a goal.

  3. Let Codex respond with normal assistant messages.

  4. Try to resume by id:

    codex resume <thread_id>

    This works, and the later assistant messages are present.

  5. Try to find it through the picker:

    codex resume

    The session is missing.

  6. 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:

Darwin 25.5.0 arm64 arm

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.

extent analysis

TL;DR

The issue can be mitigated by ensuring that a normal user message is sent before or after creating a goal with /goal to make the session discoverable.

Guidance

  • Verify that sessions starting with a normal user message and then using /goal are listed correctly in codex resume and Codex Desktop recents.
  • Test if adding a normal user message after creating a goal with /goal makes the session appear in the lists.
  • Check if using a different method to create a goal or sending a message before creating a goal affects the session's discoverability.
  • Investigate if the issue is specific to the observed platform (Darwin 25.5.0 arm64 arm) or if it occurs on other platforms as well.

Example

No code snippet is provided as the issue seems to be related to the interaction with the Codex system rather than a specific code implementation.

Notes

The issue might be related to how Codex handles sessions started with a /goal command, and it's possible that the system relies on the presence of a normal user message to properly index the session.

Recommendation

Apply workaround: Send a normal user message before or after creating a goal with /goal to ensure the session is listed in codex resume and Codex Desktop recents. This approach can help mitigate the issue until a more permanent fix is available.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#callback error#memory management#API rate limit#retriever error#indexing error

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

codex - ✅(Solved) Fix /goal-first sessions are missing from resume lists [1 pull requests, 6 comments, 3 participants]