feat(cli): show patch tasks in Codex desktop

[ianw-oai]

Summary

Patch tasks did not appear in Codex desktop because the CLI created ephemeral codex exec sessions. The desktop app also excludes saved exec sessions from its task list.

Changes

• Run patching through the bundled Codex app server and save a desktop-visible task.
• Preserve the user's project trust decision, workspace-write sandbox, approval policy, disabled plugins, and redacted failures.
• Accept output only from the parent turn, reply to unsupported client requests, and require a completed turn before reporting success.
• Keep the validation command unchanged and preserve the Linear patch flow.

Testing

• Full randomized suite: 1,311 passed, 11 skipped, zero failures.
• Focused patch, trust, and Linear tests: 31 passed.
• Generated-model check, TypeScript checks, build, formatting, and diff checks passed.
• The built CLI completed a local synthetic Responses run with the real bundled Codex binary. The task was saved with a desktop-visible source, and project trust was unchanged.
• Native integration tests cover unset, untrusted, and explicitly trusted projects.

Risk and rollout

Saved patch tasks can contain finding details. User configuration and explicitly trusted project configuration remain active. Patching does not grant project trust. The workspace-write sandbox and never approval policy remain enforced. The desktop app is optional.

Public disclosure review

• No customer, partner, prospect, or user identities, data, or identifying details are included.
• No credentials, personal data, private source, scan findings, or nonpublic links or tickets are included.
• I reviewed the branch name, title, description, commits, changes, comments, logs, screenshots, attachments, and links for public disclosure.

[mldangelo-oai]

looks great!

[mldangelo-oai]

Non-blocking follow-up to my earlier comment on 43fd1b26. The installed package's normal patch and resume path worked. The additional protocol tests found three cases worth covering: a child task can finish the parent command, a server request for user input can go unanswered, and an early disconnect can return success.

The full local suite passed 1,288 tests with 11 skipped, and the current GitHub checks are green. I left the observed behavior and suggested regression tests inline. A small app-server helper shared with #471 would give these cases one place to live.

[mldangelo-oai]

Non-blocking design summary for #475, #477, #471, and #461.

I think the split is right: keep the pinned scan runtime isolated, share task visibility, and let the user continue a saved patch task. I'd keep the implementation small:

• Preserve feat: patch Linear issues and projects #475's focused Linear adapter.
• Share one app-server client between [codex] Show security scans in the Codex app #471 and feat(cli): show patch tasks in Codex desktop #477.
• Use one patch request and result for literal issues, Linear issues, and saved findings.
• Make publication an opt-in step that shows the outgoing diff and destination and can resume after a failure.
• Keep the terminal UI focused on selection and short instructions, with a useful handoff to the saved task.

Across the four PR heads and a #475+#477 integration tree, five full local suite runs produced 6,336 passes and 55 skips. The real-model patch and saved-task resume paths worked with synthetic fixtures. The current heads do not yet provide one complete Linear issue to GitHub PR workflow; I did not use live Linear or create an external PR.

My suggested follow-up order is the #477 lifecycle tests, the #471 naming and Windows cleanup, then the common patch result and publication recovery. After those pieces are joined, one explicitly scoped live acceptance test would close the remaining gap.

Detailed notes: #475, #477, #471, #461.

[zcrab-oai]

Found a project-isolation regression in the transition from ephemeral patch execution to persistent desktop tasks.

[kmbroai]

Preapproving - should fix some of the comments