[BUG] Claude Code web VM reclamation severely Breaks the Dynamic Workflow [AFK] lifecycle: running workflows are killed mid-run

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Severity: High — a severe, silent data-loss bug.

On Claude Code on the web, the cloud inactivity reaper treats an actively-running dynamic workflow as idle. If I start a workflow and stop typing, the session's VM is reclaimed after the inactivity window even though the workflow is still executing — spawning agents and making progress. The run is destroyed mid-flight, and because workflow resume is same-session only, reopening the (fresh) VM does not continue it.

Actual behavior:

• The workflow keeps running with no user input required.
• After the inactivity window the VM is reclaimed and the session is marked expired (per the Environment expired section of the Claude Code on the web docs).
• No error is surfaced on the run; agents that were mid-run are lost.
• Reopening provisions a fresh VM with conversation history restored, but the workflow does not resume (per How a workflow runs: resume works within the same session; exiting while a workflow is running starts it fresh next time).

Because a reclaimed-then-reopened session is effectively a new VM/process, the in-memory workflow state (which agents completed, the script's loop/branch position, intermediate results) is gone. The conversation comes back; the workflow doesn't. The result is silent, unrecoverable loss of in-flight work that Claude Code itself started.

What Should Happen?

While a dynamic workflow the runtime started is still running, the session's VM should not be reclaimed. Inactivity should be measured against workflow liveness (agents in flight / the run still executing), not only user input — the same way a session that is mid-response isn't torn down.

Primary expected behavior:

• Don't reclaim a cloud VM while a dynamic workflow it started is still running. Count an active workflow as activity so the inactivity timer doesn't fire — optionally bounded by a max runtime / token budget so a runaway can't hold a VM forever, with the run stopped and partial results surfaced when the cap is hit.

Acceptable alternatives, if keeping the VM alive isn't always possible:

• Checkpoint the workflow's runtime state and auto-resume on reopen — extend the existing same-session resume across the environment-expiry boundary (cf. the local supervisor handoff CLAUDE_CODE_DISABLE_BG_EXIT_HANDOFF / adopt).
• At minimum, surface a real error / "workflow terminated" state instead of a silent kill plus a phantom "Running" entry.
• Optionally, a configurable inactivity window or a "long-running / unattended" flag at session creation.

Error Messages/Logs

None — **and that absence is part of the bug.** When the VM is reclaimed mid-workflow, no error is surfaced on the run. The session is silently marked `expired` in the session list, and per #70686 the web Background Tasks panel can keep showing the killed task as `Running` (elapsed timer still incrementing) even though no process exists in the new container. There is nothing to paste here, which is itself the problem: the failure is silent.

Steps to Reproduce

1. Open claude.ai/code and start a cloud session on a real GitHub repo.
2. Kick off a whole-repository, ground-up rewrite as a dynamic workflow — the scale the docs advertise workflows for (dozens to hundreds of agents). It is inherently long-running: analyze the entire codebase, design a target architecture, then rewrite every module to it in isolated copies and verify each one. Use the ultracode keyword or ask for a workflow. Example prompt:

   ultracode: re-architect and rewrite this entire repository from the ground up — analyze every module, design the target architecture, then migrate and rewrite each file to it in its own isolated copy and adversarially verify every change

A run this size fans out across the whole repo and runs for well over an hour, so it comfortably outlasts the inactivity window. (My original run was exactly this: a full-repo rewrite spanning many phases and hundreds of agents. It was still mid-run — roughly 1.5+ hours in — when the VM was reclaimed.)

1. Open /workflows and confirm the run is actively executing with agents in flight.
2. Stop interacting and go AFK — no user input, tab hidden — and wait out the inactivity window while the workflow keeps running.
3. The VM is reclaimed and the session shows expired while the workflow was still mid-run, long before the rewrite completes.
4. Reopen the session: a fresh VM is provisioned, conversation history is restored, but the workflow does not continue; all mid-run agents and the run's progress are gone.

Result: hours of a large, in-progress rewrite are lost — only whatever agents happened to finish and whatever was pushed to git survive. The entire run has to be restarted from scratch.

Claude Model

Sonnet (default)

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

IDK

Platform

Anthropic API

Operating System

Other

Terminal/Shell

Other

Additional Information

_No response_