feat: add task --resume-thread

[fscfede-beep]

Summary

Fixes #700.

• add task --resume-thread <id> to resume an exact persisted Codex thread
• keep --resume-last, --resume, --fresh, and explicit-thread routing mutually exclusive
• support explicit-thread resume in both foreground and detached background jobs
• allow resume without a prompt, using the existing canonical continue prompt
• pass the new routing flag through the codex-cli-runtime rescue contract
• add regression coverage proving the requested thread wins over a newer thread

The runtime already supported resumeThreadId; this change wires that capability through the companion CLI and stored background task request.

Validation

On Windows 11 / Node 26.3.1:

• test-first reproduction failed on main: explicit thr_1 created/resumed thr_3 or thr_2 instead
• focused routing regression: 9 passed, 0 failed
• command/docs regression: 8 passed, 0 failed
• detached background resume completed and fake app-server recorded threadId=thr_1
• node --check plugins/codex/scripts/codex-companion.mjs
• git diff --cached --check

The existing Node DEP0190 warning still appears on this Windows base; that is tracked separately by #717 and addressed by PR #725, not introduced here.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: cacf2270c1

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Bypass rescue auto-routing for explicit threads

When /codex:rescue --resume-thread <id> is used while task-resume-candidate reports an existing current-session task, the upstream commands/rescue.md flow does not recognize this new routing flag, so it asks the continue/new-thread question and then prepends either --resume or --fresh. The companion subsequently rejects that request as conflicting, making explicit-thread resume unusable in this common scenario. Add --resume-thread to the rescue command's explicit-routing checks so it skips the candidate prompt and forwards the requested thread unchanged.

Useful? React with 👍 / 👎.

[fscfede-beep]

Addressed the P1 explicit-thread routing feedback in 08cd208: /codex:rescue --resume-thread <id> now bypasses automatic continue/new routing, and the rescue subagent preserves the exact thread instead of adding --resume-last. Command/docs regression: 8/8 PASS; task routing regression remains 9/9 PASS.

@codex review

[chatgpt-codex-connector]

Note

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

[sylvesterkaczmarek]

Exact-thread precedence and the mutual-exclusion rules are coherent across foreground, background and rescue paths. One ownership boundary is worth pinning: --resume-thread bypasses the workspace/session candidate resolver and forwards the supplied thread ID directly to app-server. Please add a regression with a thread created under another repository proving native resume rejects or safely rebinds a foreign cwd rather than executing that thread in the current task workspace.

[fscfede-beep]

Pinned this boundary in 44eea53 and verified it against a real Codex app-server, not only the fake fixture.

Native behavior on codex-cli 0.149.1 with two throwaway repositories:

1. Started the thread in repo A (marker.txt = A); the task returned A.
2. Tried to resume that same thread ID from repo B while repo A still had the thread loaded; Codex rejected it with thread <id> already has an active writer.
3. Ended the repo A session/broker, then resumed the same thread ID from repo B (marker.txt = B); the resumed task kept the same thread ID and returned B.

This matches the current Codex app-server contract: ThreadResumeParams.cwd is a configuration override for a resumed thread. The plugin already passes the current workspace cwd to thread/resume; 44eea53 adds a regression that creates the thread under repo A and resumes it under repo B, and updates the fake app-server to mirror the native cwd-override semantics so dropping that forwarding in the future will fail the test.

Validation: resume-thread runtime 4/4 PASS; commands/docs 8/8 PASS; fixture/runtime syntax and git diff --check clean.