claude-code - 💡(How to fix) Fix [BUG] Intentional kill of a backgrounded Bash task is reported as "failed" exit 144 with no way to mark cleanup as expected

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

Error Message

Error Messages/Logs

Fix Action

Fix / Workaround

Workaround currently in use: prefer bounded background pipelines like tail -f | grep --line-buffered | awk '/PATTERN/{exit}' so the watcher self-terminates on the event of interest and produces a normal completion. Works for "watch until X happens" but not for "watch indefinitely until I say stop."

Code Example

<task-notification>
<task-id></task-id>
<status>failed</status>
<summary>Background command "…" failed with exit code 144</summary>
</task-notification>

---

<task-notification>
<task-id>bp9313az1</task-id>
<tool-use-id>toolu_013WEw2DsaotvAfaYg5qYu3V</tool-use-id>
<output-file>/tmp/claude-/tasks/bp9313az1.output</output-file>
<status>failed</status>
<summary>Background command "Capture next single turn and exit" failed with exit code 144</summary>
</task-notification>

(Three of these in the session of 2026-05-25, all from intentional cleanups, none from real failures.)
RAW_BUFFERClick to expand / collapse

Preflight Checklist

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

What's Wrong?

A Bash call with run_in_background: true started against an unbounded watcher (e.g. ssh host "journalctl -u svc -f | grep --line-buffered PATTERN") can only be stopped later by pkill on the wrapping process. When the agent does that — as part of normal "stop watching now" cleanup — the harness emits a <task-notification> of the form:

<task-notification>
<task-id>…</task-id>
<status>failed</status>
<summary>Background command "…" failed with exit code 144</summary>
</task-notification>

Exit 144 is the expected result of the pipeline receiving SIGTERM via that intentional pkill — the cleanup succeeded. But the notification is indistinguishable from a real crash. In one of today's sessions, three separate user-requested cleanups surfaced as three "failed" events; the user reasonably read the cascade as my work breaking and asked what I was doing wrong.

This punishes the correct usage pattern (start watcher → kill it when done), pushes models toward fragile alternatives (polling loops that miss events; never backgrounding tails at all), and clutters transcripts so genuine failures are harder to skim for.

What Should Happen?

Any of (escalating):

  1. A mark_intentional_termination action on backgrounded tasks (the Bash equivalent of TaskStop) that exits with status: terminated rather than failed.
  2. A heuristic: if the same conversation issued a pkill/kill against the wrapper process within the last few seconds, classify as terminated.
  3. At minimum, distinguish exit codes 143 (SIGTERM) and 144 (SIGTERM-during-pipe) from arbitrary non-zero exits in the summary text: Background command "…" terminated by signal vs failed.

Error Messages/Logs

<task-notification>
<task-id>bp9313az1</task-id>
<tool-use-id>toolu_013WEw2DsaotvAfaYg5qYu3V</tool-use-id>
<output-file>/tmp/claude-…/tasks/bp9313az1.output</output-file>
<status>failed</status>
<summary>Background command "Capture next single turn and exit" failed with exit code 144</summary>
</task-notification>

(Three of these in the session of 2026-05-25, all from intentional cleanups, none from real failures.)

Steps to Reproduce

  1. Bash(run_in_background: true, command: "ssh host 'tail -f /var/log/somefile'")
  2. Do work that uses the watcher's output.
  3. Bash(command: "pkill -f 'ssh host.*tail -f /var/log/somefile'") to stop the watcher.
  4. A few seconds later, a <task-notification> arrives with status: failed and exit code 144 for the background task.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

No response

Claude Code Version

2.1.150

Platform

Anthropic API

Operating System

Other Linux

Terminal/Shell

Other

Additional Information

Platform

linux (WSL2)

Operating System

Linux 6.6.87.2-microsoft-standard-WSL2

Terminal/Shell

bash

Additional Information

Workaround currently in use: prefer bounded background pipelines like tail -f | grep --line-buffered | awk '/PATTERN/{exit}' so the watcher self-terminates on the event of interest and produces a normal completion. Works for "watch until X happens" but not for "watch indefinitely until I say stop."

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING