Feature request: external run-control API for dynamic workflows (pause/resume/stop by runId)

Open 💬 0 comments Opened Jul 5, 2026 by michaelandrewgamble

Problem

Dynamic workflow runs can only be controlled (p pause/resume, x stop, r restart-agent) from inside the session that owns them — via the /workflows TUI or by asking that session's Claude to call TaskStop/Workflow({resumeFromRunId}). There is no CLI flag, SDK primitive, or file-based mechanism to control a run from outside its owning process. claude --resume <session> starts interrupted workflows fresh rather than attaching to them.

Real-world failure this causes

While working in a Cursor extension chat, I interrupted the conversation, which aborted a 4-agent workflow ~19 minutes in (Error: Workflow aborted, status killed). The only recovery was a full fresh re-run — the journal's cached agent results were unreachable from any new process, and no other surface (terminal CLI, Desktop, or a monitoring tool) could have stopped, paused, or rescued the run either.

What exists today (verified)

  • Run state on disk (~/.claude/projects/<proj>/<session>/workflows/wf_*.json + journals) is written only at terminal status — nothing external can even reliably distinguish running/paused/crashed, let alone act.
  • The Agent SDK has session primitives (listSessions, forkSession, resume) but no workflow-run primitives.
  • The interactive /workflows panel is not dispatchable headlessly.

Ask

Any one of these would unblock out-of-process run management (in rough preference order):

  1. SDK/CLI primitives: listWorkflowRuns(), pauseWorkflowRun(runId), resumeWorkflowRun(runId) (with journal-cache reuse), stopWorkflowRun(runId) — e.g. claude workflow stop wf_xxx.
  2. A control-file contract: the owning runtime watches a well-known path (e.g. <runDir>/control) for pause|resume|stop commands.
  3. Cross-process journal-replay resume: make Workflow({resumeFromRunId}) work from a new session when the original is gone, reusing cached agent results from the journal.

Context

I maintain workflows-conductor, an open-source dashboard/plugin that reconstructs full workflow observability from the on-disk artifacts across all projects and surfaces. Observation is solved; control is the one capability that cannot exist without runtime support. Related: #72292 (extension /workflows parity).

View original on GitHub ↗