Background workflows die silently, with no error and no surfaced cause

Summary

Two of four background Workflow runs in a single Claude Code session terminated mid-run. The
application stayed up. No error reached the user, no reason was recorded, and in the first case every
completed subagent result was lost. The only signal was a later notification saying no completion record
was found.

I am reporting two defects. The first stands regardless of root cause. The second is a strong hypothesis
with a controlled test behind it.

Defect 1. A workflow can stop existing without reporting why. Something in the runtime knows the run
ended, because the desktop log records a lifecycle event for every run that finishes or is stopped
cleanly, and records nothing for the two that died. The user is told only that no completion record was
found, which describes the absence of a record rather than the failure.

Defect 2 (hypothesis). Browser and computer-use MCP tools are reachable from a workflow subagent and
appear to be fatal when called. A background sidechain agent calling preview_start against the
application's foreground browser pane killed both runs within seconds.

Environment

• Claude Code desktop app on Windows 11 Pro 10.0.26200
• Model Opus 5 for the second failure, Opus 4.8 for the first, so the failure is model independent
• Electron process tree of 10 processes, 1.7 GB RSS, 32 GB installed
• Session ran roughly six hours with heavy tool use

Evidence

Workflow lifecycle records discriminate perfectly

From %APPDATA%\Claude\logs\main.log. Every run that completed or was stopped through TaskStop
recorded an end event. Neither failed run did.

| Run | Workload | Started | Ended | Outcome |
|---|---|---|---|---|
| wwl1ya7z6 | 12 agents, web research | 18:54:18 | none recorded | died |
| w8d28pfos | 2 agents, ping only | 19:23:17 | 19:24:20 | completed |
| wjq0rmyou | 2 agents, ping only | 19:25:11 | 19:26:12 | completed |
| wmcfctaos | 3 agents, web research | 19:37:53 | 19:56:22 | stopped by me, recorded correctly |
| wev1ppp7r | 1 agent, web research | 19:58:19 | none recorded | died |

The missing end event is a reliable detector. It is also the only trace the failure leaves.

The suspected trigger, timed to the second

The Claude-Browser MCP log for the second failure, at
%LOCALAPPDATA%\claude-cli-nodejs\Cache\<project>\mcp-logs-Claude-Browser.

00:59:08.517Z  Calling MCP tool: preview_start     completed successfully in 3s
00:59:13.397Z  Calling MCP tool: get_page_text     completed successfully in 33ms

The subagent's final transcript write was 19:59:16 local, three seconds after get_page_text returned.
Neither I nor the workflow script requested a browser tool. The subagent loaded them itself through
ToolSearch.

The first failure shows the same pattern. preview_start, three navigate calls, get_page_text and
read_page between 18:54:51 and 18:55:29, immediately before that run died.

Why it reproduced on one specific task

Subagents researching regulations succeeded, because WebFetch reaches those hosts. The subagent
researching employers needed job boards and careers sites, which bot-block. It received three identical
830 byte refusals from a major hospital system's careers site, then escalated to the browser MCP to
read the page, then died. That same task failed twice. The two runs that used no web tools at all, only a ping timer,
both completed.

What I eliminated, with evidence

| Candidate | Evidence against |
|---|---|
| Large session transcripts | The live session transcript was 0.5 MB. The failed run's subagent transcripts totalled 4.7 MB. I separately reclaimed 287 MB of inlined base64 images from historical transcripts, which changed nothing. |
| Memory pressure or OOM | The app's own [process-memory] census ran continuously through both failures at 1.7 GB RSS with 16.7 GB free of 32 GB. No OOM marker in any app log. |
| Application crash | No APPCRASH for claude, node or electron in the Windows Application log. main.log continued writing without a gap. The app never died. |
| Interruption of the launching turn | Tested directly. A control run and a run interrupted by three mid-turn user messages both completed. |
| Concurrency | The second failure died with one subagent running, before the parallel phase was reached. |
| Large tool payloads | Every record in the dying subagent's transcript was 1 to 4 KB, largest 32 KB. |

A WUDFHost.exe heap corruption cluster (0xc0000374) appears in the Windows log at 18:34:56 to 18:35:19.
It falls between the two failures and looks unrelated.

Impact

The first failure lost five completed research subagents. journal.jsonl was zero bytes, so nothing was
recoverable and resumeFromRunId had nothing to replay. Results existed only in the orchestrator's
memory until the run returned, so process death destroyed all of it.

I worked around this by requiring every subagent to write its findings to disk before replying. A later
manual stop then cost only the in-flight agent, and two completed dives survived as files. That workaround
should not be necessary.

Suggested fixes

1. Surface a reason when a workflow terminates abnormally. Any diagnostic beats a missing completion

record, which reads to the user as a lost job with no cause.

1. Journal each agent result as it completes, so a mid-run death preserves finished work.
2. Decide whether browser and computer-use MCP tools belong in a sidechain tool surface. If they do not,

exclude them so an agent cannot load them through ToolSearch. If they do, make the call non-fatal.
The current behaviour punishes an agent for a reasonable decision, which is to open a browser when a
page blocks WebFetch.

Reproduction sketch

1. Launch a Workflow whose subagent must research content on a bot-blocking host. A large hospital

system's careers site reproduced it for me; the exact host is available on request.

1. Give the subagent WebSearch and WebFetch and no instruction against browser tools.
2. Observe the subagent receive repeated short refusals, load the browser MCP through ToolSearch, call

preview_start, and the run terminate within seconds.

1. Confirm in main.log that the run recorded a start event and no end event.

Status of the hypothesis

Two occurrences, two clean negative controls, and a mechanism. That is correlation, not proof. I ran a
controlled fourth attempt with the browser and computer-use tools explicitly forbidden in every subagent
prompt, and instructions to record a blocked fact as unverified rather than escalate to a browser.

The guarded run completed. Run w94dw8639, started 20:05:05, 5 subagents, 0 errors, 31 minutes,
167 tool uses. The subagent task that had killed both prior runs, researching employers on bot-blocking
careers sites, finished and wrote its output. Same task, same blocking hosts, same model tier, one variable
changed.

That gives the following picture across six runs.

| Condition | Runs | Result |
|---|---|---|
| Subagents call browser MCP | 2 | both died, no end event recorded |
| Subagents use no web tools (ping only) | 2 | both completed |
| Subagents do web research, browser MCP forbidden | 1 | completed |
| Stopped through TaskStop | 1 | ended cleanly, recorded correctly |

The correlation is consistent across every run in the session, and the one controlled change removed the
failure. I still call it correlation rather than proven causation, because I cannot see inside the runtime
and I have not isolated what specifically fails when a sidechain drives the browser pane. Defect 1 stands
on its own either way.

Artifacts available on request

Workflow scripts, subagent transcripts, journal.jsonl for each run, the Claude-Browser MCP logs, the
relevant main.log extracts, and the Windows Application and System log queries.