Show /goal-started threads in resume picker#20800
Closed
etraut-openai wants to merge 7 commits into
Closed
Conversation
b5c12d6 to
4574639
Compare
jif-oai
requested changes
May 4, 2026
jif-oai
left a comment
Collaborator
There was a problem hiding this comment.
I don’t think we should fix this by writing a fake /goal ... user message into the rollout. That solves the resume-picker symptom, but it does it by forging synthetic transcript history, and that leaks into a bunch of other behavior... (history, title, state, ...). TBH I'm not convinced this is the good layer to patch this
This was referenced May 7, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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
/goal <objective>user message so existing preview/listing logic can surface the thread.Alternative considered
Another viable fix would be to treat goals as resumable metadata in the listing stack: include
thread_goalsrows whosethreads.first_user_messageis empty, merge those metadata-only rows throughcodex-rolloutandcodex-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/setand only runs when a goal objective is set on a running thread.