Feature request: external run-control API for dynamic workflows (pause/resume/stop by runId)
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
/workflowspanel is not dispatchable headlessly.
Ask
Any one of these would unblock out-of-process run management (in rough preference order):
- SDK/CLI primitives:
listWorkflowRuns(),pauseWorkflowRun(runId),resumeWorkflowRun(runId)(with journal-cache reuse),stopWorkflowRun(runId)— e.g.claude workflow stop wf_xxx. - A control-file contract: the owning runtime watches a well-known path (e.g.
<runDir>/control) forpause|resume|stopcommands. - 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).