Add task --resume-thread <id> for explicit thread resume#475
Open
Guardiannw wants to merge 1 commit into
Open
Conversation
--resume/--resume-last picks the newest tracked task thread, which is ambiguous for orchestrators driving several concurrent Codex jobs in one repository: the thread that gets resumed depends on job-store state and session scoping rather than the caller's intent. The app-server layer already supports targeting a thread (runAppServerTurn resumeThreadId); this exposes it on the task subcommand so callers that recorded a threadId from a previous run (task --json) can continue that exact conversation. - task --resume-thread <id> resumes the given thread (foreground and --background; the worker path serializes resumeThreadId through the stored request) - conflicts with --resume/--resume-last/--fresh are rejected - a prompt remains optional, matching --resume-last semantics Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
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
1 participant
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.
Summary
Adds
task --resume-thread <id>so callers can resume an explicit Codex thread instead of the newest tracked one.--resume/--resume-lastpicks the most recent tracked task thread, which is ambiguous for orchestrators driving several concurrent Codex jobs in one repository: which thread gets resumed depends on job-store state and session scoping rather than the caller's intent. The app-server layer already supports targeting a thread (runAppServerTurn'sresumeThreadId); this exposes it on thetasksubcommand so a caller that recorded athreadIdfrom a previous run (task --json) can continue that exact conversation deterministically.Changes
task --resume-thread <id>resumes the given thread (foreground and--background; the worker path serializesresumeThreadIdthrough the stored request).--resume/--resume-last/--freshare rejected with a clear error.--resume-lastsemantics (the default continue-prompt is used when none is given).Tests
task --resume-thread resumes the specified thread— round 1task --jsoncaptures athreadId, round 2 resumes it and asserts the same thread + continued output.task --resume-thread rejects --resume-last and --fresh.npm test): 93 passing.Motivation
We drive Codex as a multi-round peer reviewer from Claude Code. Round 1 records the
threadIdfromtask --json; subsequent rounds need to resume that thread. Today the only CLI path is--resume-last, which is a heuristic; under any concurrency it can resume the wrong conversation. This flag makes the common "continue the thread I just started" case explicit and deterministic, using machinery the app-server already exposes.