[Bug] Claude avoids debugging and waits for results instead of proactively investigating root causes

Bug report: pkill bun silently destroys ALL running Workflow-tool workflows in a session

Component: Claude Code — Workflow tool runtime
Version: 2.1.183 (macOS, Apple Silicon M1 Max)
Severity: High (data-loss-adjacent: silent, unrecoverable loss of in-flight work; no error surfaced)
Date observed: 2026-06-21
Session: 365236ca-c49d-4782-9146-4df3920f633c
cwd: ~/work/datasources

---

Summary

The Workflow tool executes its JavaScript scripts in a shared bun runtime process. That
process is a single, shared, generically-named OS process (bun). If anything kills it — e.g. an
agent or user running pkill -9 bun during routine "zombie process" cleanup — every
concurrently-running workflow in the session dies at once, the running subagents are torn down,
and no terminal error is surfaced. The workflows simply look "stopped": their
journal.jsonl is frozen at started:N / result:0 with no abort/error event.

In this incident, an agent (Claude) running cleanup executed pkill -9 bun without knowing bun
was the workflow runtime. This killed the shared runtime and broke ~28 concurrently-launched
editing workflows. A recoverable "slow" situation became an unrecoverable "must restart" one.

Two layered problems:

1. (Product) The workflow runtime is trivially killable by name with no isolation, no

protection, and no resulting error event — killing it is silent and total.

1. (Behavioral) pkill -9 <name> on an unknown process is dangerous; tooling gives no hint

that bun is load-bearing.

---

Root cause (evidenced)

Self-review written in-session at 2026-06-21T10:00:19Z (17:00 +07), verbatim:

Lỗi 5 (tệ nhất về hậu quả): pkill -9 bun — Để dọn "zombie", tôi force-kill bun mà không biết bun là gì → giết luôn runtime workflow dùng chung → hỏng MỌI workflow còn lại trong phiên. … 4. Không bao giờ pkill -9 tiến trình runtime không hiểu rõ — chỉ dùng TaskStop.

Other verbatim fragments confirming the same cause (same session):

pkill -9 bun để dọn zombie có thể giết luôn runtime workflow dùng chung. pkill bun làm hỏng runtime. Không bào chữa.

The destructive cleanup commands actually issued (Bash tool_use in the session):

[2026-06-21T09:47:18Z = 16:47 +07]
  pkill -9 -f "datasources/edit_pipeline.py"
  pkill -9 -f "wf_edit_all"
  pgrep -c bun

[2026-06-21T09:58:00Z = 16:58 +07]
  pkill -9 -f "datasources/edit_pipeline.py"
  pkill -9 -f "wf_edit_all\|wf_upgrade\|edit-mtl"
  echo "ĐÃ STOP TẤT CẢ"

plus the directly-admitted pkill -9 bun.

Symptom signature in the transcript

Killed workflow subagents recorded only a generic interruption, never a runtime-died error:

// wf_d106f255-185 / agent-ac1247e5163012263  (16:58 +07)
{"type":"user","message":{"content":[{"type":"text","text":"[Request interrupted by user]"}]},
 "timestamp":"2026-06-21T09:58:35.324Z","sessionId":"365236ca-...","version":"2.1.183"}

// wf_59e59e16-a0e / agent-a5465c8e17aa83bd4  (16:54 +07)
{"type":"user","message":{"content":[{"type":"tool_result","is_error":true,
 "content":"The user doesn't want to proceed with this tool use. ... STOP what you are doing ..."}]},
 "toolUseResult":"User rejected tool use"}

NOTE: these read as "interrupted by user" / "tool rejected", which is misleading — the underlying cause was the shared bun runtime being killed. The interruption marker does not distinguish "user pressed Esc" from "runtime process was killed out from under the workflow".

Journal evidence (the storm)

…/365236ca-…/subagents/workflows/*/journal.jsonl, 16:12–16:56 +07:

16:37  wf_6c3aa365-e0f   started=31  result=23   ← only productive run (chapters applied up to #73)
16:12–16:56  ~28 other workflows   started=1   result=0   ← launched, never completed, no error event

---

Steps to reproduce

1. In a Claude Code session, launch one or more workflows via the Workflow tool that spawn

subagents (any script with agent() calls). Keep them running.

1. In a separate Bash tool call (simulating routine process cleanup), run:

``
pkill -9 bun
`
(or pkill -9 -f bun`).

1. Observe:

• All running workflows stop immediately.
• Each workflow's journal.jsonl is left at started:N / result:0 with no terminal

aborted/error event.

• Subagent transcripts end with [Request interrupted by user] /

tool_result is_error:true "User rejected tool use", i.e. the cause is mislabeled as a
user action rather than "workflow runtime terminated".

• No message is surfaced to the main loop explaining that the runtime died.

Minimal repro: launch any long workflow, then pkill bun from a shell → workflow dies with a
"user interrupted" marker and no runtime-death diagnostic.

---

Expected vs Actual

| | Expected | Actual |
|---|---|---|
| Killing the runtime | Surfaces a clear, specific terminal status (e.g. workflow runtime terminated) | Silent; transcript says "[Request interrupted by user]" / "User rejected tool use" |
| Journal on abort | Terminal aborted/error event per workflow | Frozen at started:N / result:0, no terminal event |
| Runtime resilience | Hard to kill all workflows by accident; isolated or protected | One pkill bun kills every workflow in the session |
| Discoverability | Tooling hints bun is the workflow runtime | bun is an opaque generic process name |

---

Impact

• Time lost, not data: every _fixed.json already applied is intact and complete

(verified ch.73 = 52/52 paragraphs; ch.5 edited=True). Total truly-edited chapters at the
freeze point = 2,214, fully resumable.

• ~19 minutes of wall-clock (16:37→16:56) produced zero additional chapters: the runtime kept

getting killed mid-setup.

• Misleading "user interrupted" labels sent the next debugging session down the wrong path

(initially mis-diagnosed as a quota limit).

---

Suggested fixes

1. When the workflow bun runtime dies, emit a specific terminal event to each affected

workflow journal and to the main loop (workflow runtime terminated (pid …)), distinct from
user interruption.

1. Write a terminal aborted/error record into journal.jsonl instead of leaving

started:N / result:0.

1. Consider isolating / naming the runtime process distinctively (e.g. claude-workflow-runtime)

so generic pkill bun cleanup does not nuke it, or guard against external SIGKILL.

1. Docs/UX: surface that Workflow runs on a shared bun runtime and should be stopped with

TaskStop, never pkill.

Behavioral note (operator side)

pkill -9 <name> against an unidentified process is unsafe. Correct action was TaskStop on the
specific workflow tasks. Do not force-kill a runtime whose blast radius is unknown.