Bash run_in_background tasks killed at turn boundary on MSYS2 MINGW64, and reported status does not match the process

Summary

On an MSYS2 MINGW64 shell, Bash tool calls launched with
run_in_background: true are terminated at the turn boundary after launch, and
the task-completion notification does not reflect what actually happened to the
process. Observed independently by two sessions on the same host.

Environment

• Claude Code 2.1.239
• Windows 11 Home 10.0.26200
• uname -a: MINGW64_NT-10.0-26200 3.6.10-8fbd9808.x86_64 2026-07-31 07:26 UTC x86_64 Msys
• Shell: MSYS2 MINGW64, installed at C:\msys64 — the MSYS2 distribution, not the Git Bash bundled with Git for Windows. Reproducing under Git for Windows may behave differently; this report is from MSYS2. Via the Bash tool, not PowerShell.

Steps to reproduce

1. Start a long-running job that writes to a file, e.g.

bash long-suite.sh > /tmp/out.txt 2>&1 with run_in_background: true.

1. Also launch a waiter whose body is dominated by sleep, e.g.

until grep -q DONE /tmp/out.txt; do sleep 30; done, with
run_in_background: true.

1. Finish the turn (produce any assistant message) and continue the session.

Expected

The background task keeps running until it finishes or is explicitly stopped,
and its completion notification reports its real outcome.

Actual

A. Background tasks are killed at the turn boundary. 13 waiter tasks of the
shape in step 2 (with sleep values from 30 to 300 seconds) each came back
status: killed at the first turn boundary after launch, with empty output.
Task ids from one session: btbhyisr2, birrx06qk, bffou1ruw, bsdmdvfzz,
ba9du180o, blwlx45dr, b4npuftvc, bvghq9d5i, boz63alzo, bu8ont2tk,
b8yas9ern, b7y0etxp5, bpbwvhy9v.

B. The reported status does not track the process. In both directions:

• Task bfr9lvua5 (bash test/run.sh, a ~1h test suite) was reported

killed, yet its child processes kept running and kept appending to the
redirect target for another ~20 minutes — confirmed with ps -ef and a
growing wc -l on the output file.

• Tasks bri6kw5e2 and bioznef6s were reported completed (exit code 0)

for runs that had been terminated by hand with kill -9 before the
notification arrived.

(B) is the more damaging half: a status line that says completed for a run
that never finished, or killed for one still running, cannot be used to decide
whether a validation run actually produced its result.

Workaround

Launching the same work detached from an ordinary foreground tool call
survives every turn boundary:

nohup ./run-batch.sh > /tmp/batch.log 2>&1 & disown

A 34-suite sequential test batch ran to completion this way across ~15 turns on
the same host where run_in_background was killed every time. The other session
reports the same workaround, with a fifo used to block on the result.

Why it matters

On this host class the background mechanism is the only option for a long
command, and an agent that relies on it either loses the run or — worse —
records a green result it never observed.