---
id: "bug-1576"
status: "fixed"
status_updated: "2026-09-24"
status_note: ""
component: "unknown"
severity: "unknown"
timestamp: "2026-08-18T03:15:00Z"
last_seen: "2026-09-19T09:00:00Z"
occurrences: 1
files: ["N/A (diagnostic/interactive Bash tool usage", "not a repo source file)"]
tags: ["pgrep", "pkill", "self-match", "diagnostic-methodology", "bash-tool", "sandbox-artifact"]
related: ["bug-1575"]
legacy: true
---

# bug-1576: Multiple interactive diagnostic Bash calls (`pgrep -af "<pattern>"`, `pkill -9 -f -- "<pattern>"`…

## Description
Multiple interactive diagnostic Bash calls (`pgrep -af "<pattern>"`, `pkill -9 -f -- "<pattern>"`, `ps -eo pid,args | grep "<pattern>"`) unexpectedly matched -- and in one case SIGKILLed -- the CURRENTLY-RUNNING Bash tool call's own wrapper shell process, not just the intended target process(es). One instance: `pkill -9 -f -- "rrv_dummy_marker_TEST1|..."` killed the invoking Bash call itself mid-script, truncating all output after the pkill line with no further commands executing (looked like a mysterious 'exit code 1, script just stops' failure).

## Environment
_Not recorded (migrated from buglog.json)._

## Reproduction
_Not recorded (migrated from buglog.json)._

## Root cause
This harness wraps every Bash tool invocation as roughly `bash -c "... && eval '<the submitted script text>' < /dev/null && ..."`. The wrapper's own process argv (visible via /proc/<pid>/cmdline and matched by `pgrep -f`/`pkill -f`/`ps ... | grep`) therefore contains the FULL LITERAL TEXT of the submitted script -- including any pattern string typed directly into that same script (e.g. inside the pgrep/pkill command's own quoted argument, or in an unrelated echo/comment). Any `pgrep -f`/`pkill -f` search run from within a Bash tool call will self-match (and, for pkill, potentially self-kill) that call's own wrapper process whenever the search pattern also appears as literal text anywhere else in the SAME submitted command block -- which is nearly unavoidable, since typing the pattern to search for IS typing it into the submitted script.

## Fix
Not a code fix (methodology only). When diagnosing process state from an interactive Bash tool call: (1) prefer reading /proc/<pid>/cmdline directly via a `for p in /proc/[0-9]*; do ...; done` scan and filtering in a way that doesn't require typing the exact search substring inline where it could also match the wrapper's own transcript (e.g. write the pattern to a variable/file first, or accept that the wrapper itself will show up as one extra line and visually distinguish it by its distinctive `bash -c "source .../shell-snapshots/... && eval '...'"` shape); (2) never assume a `pgrep -f`/`pkill -f` result of exactly 1 match confirms a target is unique -- it may be exactly 1 SELF-match with zero real matches; (3) for any pkill run interactively for diagnostic purposes (not from inside a dedicated script/process whose own argv doesn't contain the pattern), sanity-check the matched PID's `ps -o cmd` BEFORE trusting the pkill's effect, since a self-kill silently truncates the rest of that same Bash call with no distinguishing error message beyond a generic nonzero/truncated-output exit.

## Verification
_Not recorded (migrated from buglog.json)._

## References
- Related: bug-1575