[Bug] Left-Arrow keypress partially restarts workflow, orphaning live agents and re-executing completed ones

Bug Description

Bug: a single Left-Arrow keypress restarts a running background workflow — partially, killing a live agent and re-running completed ones

Claude Code version: 2.1.232
Platform: Linux (zsh), CLI, background session
Severity: high — destroys in-flight multi-agent work and silently overwrites completed on-disk deliverables
Date observed: 2026-08-15 ~00:09 (EEST)

Summary

While a background Workflow run was in progress, pressing the Left-Arrow key in the
terminal caused the workflow to restart. The restart was partial and non-idempotent:

• it re-launched two agents that had already completed (their results were in the journal), and
• it killed a third agent that was actively running (12 minutes into its work, no result recorded), and
• the relaunched agents overwrite files on disk that the completed agents had already written.

No confirmation prompt appeared. The keypress is not a documented workflow control, and
Left-Arrow is an ordinary cursor-movement key — it is pressed by accident constantly.

Expected

Left-Arrow moves the cursor in the input box. It does not control background tasks.
If some key is bound to restart/resume a workflow, it should (a) not be a bare cursor
key, and (b) require confirmation, since a workflow restart can cost many agent-minutes
and overwrite files.

Actual

A single Left-Arrow press relaunched three agents mid-run, orphaning a live one.

Evidence — the run journal

Run ID wf_a55c5517-5b3. Journal at
<project>/subagents/workflows/wf_a55c5517-5b3/journal.jsonl.
The key field is the workflow's cache key for an agent() call — the same key means
"the same call". Entries 1–8 are the normal run; 9–11 appear immediately after the
keypress:

 #  type     agentId              key (truncated)
 1  started  a609535c19e0290b1    204c1c9825   lens 1 (practice)
 2  started  a0134cb4e62324120    cb7d73a5bc   lens 2 (stack mechanics)
 3  started  aa7ac62bf0eba3ec5    b7e0ed1ba9   lens 3 (rtl/a11y)
 4  result   a609535c19e0290b1    204c1c9825   lens 1 DONE
 5  started  a805e43c8176408f7    e83518e344   refuter of lens 1
 6  result   aa7ac62bf0eba3ec5    b7e0ed1ba9   lens 3 DONE
 7  started  a2bedc3539f62eb43    ea43a0005b   refuter of lens 3   <-- live at keypress
 8  result   a805e43c8176408f7    e83518e344   refuter of lens 1 DONE
--- Left-Arrow pressed ~00:09 ---
 9  started  a72e9d696805cac47    cb7d73a5bc   lens 2 again   (legit: #2 never produced a result)
10  started  a3091e5843a7d354a    e83518e344   refuter of lens 1 AGAIN  (#8 was DONE)
11  started  aacd19f5649ec6d43    b7e0ed1ba9   lens 3 AGAIN             (#6 was DONE)

Three defects visible in entries 9–11:

1. Completed calls re-ran. Keys e83518e344 and b7e0ed1ba9 both have result

entries (#8, #6) earlier in the same journal. A resume is supposed to return cached
results for unchanged calls; these were re-executed instead.

1. A live agent was dropped. a2bedc3539f62eb43 (key ea43a0005b, started #7) was

actively writing at 00:09:17 — its transcript file was being appended to seconds
before the restart. It has no result entry and no successor started entry with its
key. It was killed and not rescheduled, so its deliverable was silently lost.

1. The restart is destructive to disk. These agents write their output files as their

deliverable. The relaunched lens-3 agent overwrites
2026-08-14-motion-rtl-a11y.md (56KB, written 23:56 by the completed run). Had I not
manually copied it aside, the completed agent's findings would have been replaced by a
fresh run's — with no diff, no prompt, and no backup.

File-mtime corroboration (same directory):

agent-a0134cb4e62324120.jsonl  23:40:22   lens 2 — died earlier (API transport error)
agent-a2bedc3539f62eb43.jsonl  00:09:17   lens-3 refuter — ALIVE, then orphaned
agent-a72e9d696805cac47.jsonl  00:09:26   \
agent-a3091e5843a7d354a.jsonl  00:09:29    > three new agents, all within 3s of keypress
agent-aacd19f5649ec6d43.jsonl  00:09:29   /
journal.jsonl                  00:09:29

Context that may matter for the repro

• The workflow was launched with the Workflow tool (script inline), running in the

background; the session is a background job.

• One agent (a0134cb4e62324120, lens 2) had already failed earlier at 23:40 with

API Error: Connection lost mid-response ("error":"server_error",
isApiErrorMessage":true in its transcript). So at the moment of the keypress the run
contained one failed call, three completed calls, and one in-flight call.

• That mixed state may be what the keypress triggered a resume against — i.e. the bug may

only reproduce when a run has a failed agen…
Note: Content was truncated.