Add user-facing continue/recover action for interrupted native sessions

[alucero270]

What problem are you trying to solve?

The concrete OpenCode report in #744 was not only about token reuse. A run produced useful work and exposed a native OpenCode sessionID, but then ended canceled, leaving the user without an obvious way to continue from the actual agent session that did the work.

#4629 solves normal follow-up session reuse for OpenCode/Codex/Pi/AMR, but it does not by itself define a user-facing recovery action for interrupted runs. Once sanitized recovery metadata exists, users need a clear action when a run has a safe recoverable native session.

I searched existing open issues for user-facing native-session continue/recover actions and only found #744 as the umbrella.

Describe the solution you'd like

Add a user-facing recovery action for interrupted native sessions, available from both the web UI and the od CLI when applicable.

Suggested behavior:

• show a continue/recover action only when the daemon has a safe recoverable native session for the run/conversation/agent
• start the next run using the stored native session when all resume guards pass
• fall back to full transcript recompose if the stored native session is stale or unsafe
• make the action understandable without exposing raw native session handles by default
• preserve normal chat follow-up behavior from feat(daemon): native session resume across turns (codex / opencode / pi / AMR) #4629; this issue is for explicit recovery from interrupted/canceled/ambiguous runs
• keep output preservation concerns linked to Preserve OpenCode output when linked-repo run ends with SIGTERM #2760 rather than hiding them inside this action

Acceptance criteria:

• Web UI exposes the action from the appropriate run details/debug/recovery surface.
• CLI exposes the same capability through an od command or flag using the same daemon API.
• The action is hidden or disabled when no safe native session is available.
• Guard failure falls back safely instead of skipping transcript history.
• Tests cover at least one recoverable native-session run and one stale/unsafe session fallback.

Alternatives you've considered

Tell users to manually copy the native session id and run the CLI themselves. That is not a coherent Open Design recovery experience and breaks the local-first product abstraction.

Only rely on the next normal chat turn. That handles happy-path follow-ups after #4629, but it does not address the interrupted-run UX that motivated the OpenCode case in #744.

Additional context

Related:

• Alternative path: use native CLI resume/continue plus sessionMap instead of full transcript reinjection on every turn #744 umbrella native-resume/sessionMap issue
• Preserve OpenCode output when linked-repo run ends with SIGTERM #2760 output-preservation bug for useful output dropped after canceled runs
• feat(daemon): native session resume across turns (codex / opencode / pi / AMR) #4629 OpenCode/Codex/Pi/AMR native resume implementation
• feat(daemon): resume cursor-agent CLI session across chat turns #4790 cursor-agent native resume slice

Would you be willing to contribute a PR?

Yes, I can take this on.

Agent-agnostic scope clarification

The recovery action should be a generic Open Design capability, not an OpenCode-specific button.

The UI/CLI wording can use the selected agent's label, but the daemon API should work for any adapter that satisfies the shared session-map and invalidation policy, including Pi and ACP/native agents such as Hermes. The action should ask the shared resume layer whether continuation is safe, then let the adapter perform its own continuation mode (--resume, --continue, ACP session/load, session-file resume, etc.).

---

PR checklist

Issue-backed PR: #5271 was converted directly into this ready-for-review PR.

Why

The web chat already exposes the guarded Continue action for resumable failed runs on main. This PR adds the matching headless CLI action so users and agents can recover a resumable native-session run without copying raw native handles or replaying the original prompt from scratch.

What users will see

od run continue <runId> checks the daemon run status, refuses runs without resumable: true, and starts a normal follow-up run in the same project/conversation/agent with the same resume_continue analytics marker used by the web action. --follow, --json, --message, and --prompt-file are supported through the existing run CLI flag patterns.

Surface area

• UI - existing web Continue CTA remains unchanged and was covered by its focused test.
• Keyboard shortcut
• CLI / env var - adds od run continue <runId>.
• API / contract - uses existing GET /api/runs/:id and POST /api/runs.
• Extension point
• i18n keys
• New top-level dependency
• Default behavior change
• None

Screenshots

N/A - no new UI surface in this PR.

Bug fix verification

• This is a recovery capability slice, not a bug fix. The new CLI tests cover a resumable native-session run and refusal of a stale/unsafe non-resumable run.

Validation

• pnpm exec vitest run -c vitest.config.ts tests/run-cli.test.ts from apps/daemon - 2 passed.
• pnpm exec vitest run -c vitest.config.ts tests/components/ChatPane.resume-failed.test.tsx from apps/web - 3 passed.
• pnpm --filter @open-design/daemon typecheck - passed.

Validation note

I also attempted pnpm exec vitest run -c vitest.config.ts tests/run-cli.test.ts tests/run-resume-on-failure.test.ts from apps/daemon. The new run-cli.test.ts passed there, but the pre-existing fake-Claude runtime resume test failed locally while not exercising the new CLI command. I kept the focused CLI and web CTA validations above as the relevant checks for this PR.

[alucero270]

/claim

[lefarcen]

Hey @alucero270 — this split makes sense.

We already have part of the runtime path in place from the recent native-resume work: the daemon persists resumable sessions, marks resumable failed runs, and the web chat already has a "Continue the run" path for interrupted sessions. What still seems missing is exactly the user-facing recovery surface you're calling out here: an explicit recover/continue action that depends on safe daemon-side resume metadata instead of exposing raw native handles.

I also think the boundary with #5270 is a good one: that issue can define the sanitized run-details/debug contract, while this one can consume it in the web UI + od CLI and keep the fallback behavior honest when the stored session is stale or unsafe. Happy to review if you take this one on.

[lefarcen]

Hey @alucero270 — thanks for picking this up.

Roughly how long do you think it'll take: a few hours, 1–3 days, around a week, or longer?

[alucero270]

Timeline: longer / unsure until #5270 lands and #744 sequencing is confirmed. I’ll treat this as dependent on the sanitized recovery metadata contract, then wire web UI + od CLI through the same daemon API rather than exposing raw native handles.

[lefarcen]

That dependency chain makes sense — treating this as blocked on #5270 plus the #744 sequencing is the right split.

I’m routing it to the product lead for direction on sequencing/scope, and we should have that clarified within about 12 hours. Your plan to wire both the web UI and od CLI through the same daemon API is exactly the boundary we want here.

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, you can upgrade your account or add credits to your account and enable them for code reviews in your settings.

[lefarcen]

🧪 Queued for QA validation — this PR changes a user-facing recovery path, so we'll run a manual QA pass before it merges. Nothing needed from you; we'll update here once that's validated. Thanks for the contribution! 🙏

[mrcfps]

@alucero270 I reviewed the changed CLI path and the new daemon CLI tests. The od run continue <runId> flow gates on the existing run status resumable flag, preserves the original project/conversation/agent context, sends the same resume_continue analytics marker as the web action, and uses the existing /api/runs creation path so the daemon resume guard remains the source of truth. The focused tests cover both the recoverable path and the non-resumable refusal path. Thanks for adding the headless recovery surface and keeping it aligned with the existing web affordance.

_{🔁 Powered by Looper · runner=reviewer · agent=codex · An autonomous AI dev team for your GitHub repos.}

[open-design-crew]

Product approved. A guarded CLI recovery action brings native-session continuation to headless workflows while preserving the same safety model as the web experience.

[open-design-crew]

Product approved. This is ready to merge.

[AmyShang-alt]

QA 验收记录

验收范围：

• PR #5271 当前 head c77c8782fd9f750adba7c857ed51189a1237041b。
• 验证新增的 od run continue <runId> CLI recovery action，以及它对 resumable / non-resumable run 的处理。
• 补充确认 daemon typecheck 和既有 Web Continue CTA focused test 未回归。

已验证：

• pnpm --dir apps/daemon exec vitest run -c vitest.config.ts tests/run-cli.test.ts 通过，覆盖可恢复 run 会通过 /api/runs 创建 follow-up run，且不可恢复 run 会拒绝并不会创建新 run。
• pnpm --filter @open-design/daemon typecheck 通过。
• pnpm --dir apps/web exec vitest run -c vitest.config.ts tests/components/ChatPane.resume-failed.test.tsx 通过。
• GitHub checks 当前主要 CI 项均为 pass，包括 Preflight、E2E Vitest、Workspace unit tests、UI P0 smoke 和 UI P0 project-runtime。

未验证：

• 未启动真实 daemon 执行一次端到端的用户 run 恢复；本次验收以新增 CLI 单测、typecheck、Web focused test 和当前 CI 为准。

风险/关注点：

• 这是 CLI + daemon run recovery 的用户可见能力，风险点在于必须只允许 resumable: true 的 run 继续。本 PR 没有绕过 daemon resume guard，CLI 侧也覆盖了 non-resumable 拒绝路径，风险可接受。

结论：

• 验收通过。可以移除 needs-validation 并标记 validated。