Module cmd_resume 

path resume <input> — fetch / load a Toolpath document, pick an installed coding-agent harness, project the session into that harness’s on-disk layout, and exec the harness’s resume command.

Inputs

<input> is resolved in this order:

1. https:// / http:// URL → fetched via pathbase-client, cached unless --no-cache.
2. owner/repo/slug shorthand → same Pathbase fetch flow.
3. Existing file path → read directly.
4. Otherwise treated as a cache id under ~/.toolpath/documents/.

Harness selection

With --harness X, X is validated against $PATH and used. Without --harness, an fzf picker shows installed harnesses with the source harness pre-selected. Source comes from path.meta.source (claude-code, gemini-cli, codex, opencode, pi) with actor-string fallback.

Project directory

-C / --cwd P overrides the shell cwd. The harness is exec’d with cwd set to P and the on-disk projection is keyed on P.

Launch

On Unix the harness binary is execvp’d, replacing the current process. On Windows it’s spawned and waited on with the exit code propagated. If exec itself fails (e.g. the binary disappears between PATH check and exec), the recipe is printed to stderr.

Exec is mockable via ExecStrategy: production uses RealExec, integration tests use RecordingExec to capture (binary, args, cwd) without launching anything.

Remote

--remote <user@host> (Claude only) resumes the session on an ssh host under tmux instead of this machine. The flow lives in the remote module: two read-only probes, the printed plan (--dry-run stops there), then upload, launch, and attach as the remote state requires; --no-attach prints the attach command after the launch instead of attaching; arguments after -- reach the remote claude. With --remote, -C names the remote project directory; the default is the local cwd with the local home swapped for the remote home. All of it compiles only with the resume-remote cargo feature on unix.

See docs/superpowers/specs/2026-05-08-path-resume-command-design.md for the full design.

Structs

CapturedExec

What exec_harness saw (for tests).

RealExec

Production implementation. On Unix this never returns on success (the current process is replaced); on Windows it spawns the child, waits, and propagates the exit code.

RecordingExec

Recording strategy for tests. captured() returns the most recent invocation.

ResumeArgs

Traits

ExecStrategy

Pluggable exec backend. Production uses RealExec (execvp on Unix, spawn-and-wait on Windows). Tests use RecordingExec.

Functions

run

run_with_strategy

Internal entry point that the integration tests call with a RecordingExec strategy. Production callers use run.