[FEATURE] Surface workflows still running in another session for the same project

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

A new session cannot tell whether a workflow is still running for the same project, and that ambiguity can silently destroy work.

My editor (VSCode) crashed partway through a multi-agent workflow. I reopened it and started a new session. /workflows was empty and TaskList returned nothing, so as far as that session was concerned, nothing was running.

The workflow was in fact still running the entire time. The crash took out the editor window, not the process behind it. The old session kept executing, kept writing to my repo, and went on to finish a stage and spawn two more agents on its own. I only noticed because I still had the old session open on another device and could watch new agents appear there.

The dangerous part is not the lost visibility, it is what you naturally do next. From the new session it looks exactly like a dead run, so the obvious move is to work out where things left off and relaunch. Do that while the old run is still going and you have two orchestrators editing the same files at once. Nothing warns you.

I only avoided it because I checked whether the old process was still alive before starting anything. Had I trusted the empty panel, I would have lost hours of work.

In short: an empty workflow list currently means both "nothing is running" and "something is running that you cannot see", and there is no way to tell those apart from inside the new session.

Two things also made the manual workaround (reading journal.jsonl and the agent-*.jsonl transcripts directly) error-prone:

• counting finished results against the number of agents you know about is not a valid "is it done" test, because a script with a loop or a conditional can spawn more. I got this wrong and briefly believed a run had finished when it had in fact just started another agent
• an agent transcript can sit idle for tens of seconds during a long model turn, which looks identical to a hang

Proposed Solution

Let a session discover workflow runs that are still active for the same project, even if it did not start them, and even if the view is read-only.

Something as small as /workflows listing "run wf_abc is active, started 14:32 in another session, currently on stage fix:r1" would be enough. The goal is not control, it is knowing the run exists before you do something that conflicts with it.

A natural companion, if cheap: warn when starting a workflow that would write files an active run is already writing.

Alternative Solutions

• Allow attaching to (or read-only following of) a live run from another session. More useful, but more work, and not required to fix the safety problem.
• Have a new session detect an active run and refuse to start a conflicting workflow outright, rather than just warning.
• Surface it outside the workflow list entirely, for example a startup notice when a project has an active run owned by another session.

I deliberately am not asking for cross-session resume here, since that overlaps existing reports (see below). Visibility alone solves the destructive case.

Priority

Medium

Feature Category

Workflow / session management

Use Case Example

Long-running multi-agent workflows that write to the repo, where the editor or client can crash while the work continues. Any setup where a user might reasonably open a fresh session and assume a silent workflow panel means nothing is in flight.

Additional Context

Related but distinct existing issues, none of which cover discoverability of a live run from another session:

• #80249 - background workflow dies at a session boundary and the suggested resumeFromRunId silently re-runs everything
• #78215 - resumeFromRunId never hits the journal cache, so re-executions discard completed results
• #49790 - session should survive client disconnect (Desktop SSH), which is the same theme from the client side

For completeness, what exists today as far as I can tell: resumeFromRunId is same-session only, so a new session cannot address the old run at all; resume is replay-from-cache rather than reattach, so there is no way to join a run that is currently executing; and resuming requires stopping the prior run first, meaning even from the original session, reclaiming a live workflow means killing it and losing whatever the in-flight agent was doing.

To be fair, the fact that the workflow survived the editor crashing is genuinely good and it saved the run. The gap is only that there is no way to find it again from a new session afterwards.

Environment: Claude Code in VSCode on Windows 11, long-running session.