[BUG] Background Bash task's process group is SIGKILLed mid-run when the command spawns a daemonizing CLI (cursor-agent) — and reported as completed (exit code 0)

The exit code 0 on a killed group is the part I'd argue makes this a correctness bug rather than a UX one, and it's worth separating from the SIGKILL itself — they'll likely need different fixes.

An agent consuming that notification has no way to distinguish "task finished, output empty because there was nothing to say" from "task was killed, output empty because it never got written". It reads a 0-byte file from a task the harness explicitly reported as successful, and proceeds on it. The failure then surfaces somewhere much later and looks like a model mistake rather than a lost task.

One thing I don't think is on your list, from hitting a different trigger of the same shape (a Go HTTP server started with & inside a background Bash call, macOS, no cursor-agent involved — mine died when the parent call hit its timeout, so it is NOT your spontaneous-kill repro and I don't want to muddy it): moving the child out of the task's process group survives it. setsid, or nohup … & disown, means a group-wide signal can't reach the child. In my case that took a process that reliably died at the parent's exit to one that outlived several subsequent calls. Worth a run on your 9-run harness — if the CLI survives under setsid while the task shell still dies, that isolates the kill to the group rather than to anything about the CLI's own daemonization, which would narrow your hypothesis usefully.

The defensive pattern that has held up for me regardless of cause: don't let a task's exit status be the proof it worked. Have the command write a sentinel as its own last act (… && touch .done) and treat a missing sentinel as failure even on exit 0 — the sentinel is created by the work, so it can't be forged by the reporting layer. You're already using touch markers diagnostically here; the same trick works as a permanent guard, and it's cheap enough to leave in.

Happy to run the setsid variant against a daemonizing CLI on my side if a second data point on different hardware would help.

Ran the setsid variant you suggested — it discriminates exactly the way you hoped.

Setup: same background Bash task shape, but the CLI is detached into its own session before exec, with output going straight to a file:

perl -MPOSIX -e 'POSIX::setsid()==-1 and die; exec @ARGV' -- \
  agent -p --output-format json ... > out.json 2>&1
echo "post rc=$?"; touch done-marker

(macOS has no setsid(1), hence the perl shim.)

Results (3 trials):

| trial | task shell (stays in task's pgroup) | CLI (own session via setsid) |
|---|---|---|
| 1 | SIGKILLed (no done-marker, capture truncated) | survived, wrote complete valid JSON to the file after the shell was already dead |
| 2 | survived | completed |
| 3 | survived | completed |

Trial 1 is the discriminating case: the shell died mid-run exactly as before, but the CLI in its own session was untouched and finished writing its response (validated as parseable JSON with the expected result field). So the kill does not reach outside the process group — it's a group-targeted SIGKILL, not a tree walk over descendants. That also fits the earlier negative result that plain pipe-holding children (sleep 600 &) never trigger anything: whatever fires the kill is specific to this CLI's startup, and my current best guess is the harness's cleanup misreading the daemonization dance (double-fork/setsid of the worker-server causes rapid membership churn in the group) as "task finished, reap the group" — which would also explain both the ~20% survival rate (it's a race) and the exit-0 report (cleanup path believes it's normal completion). That last part is speculation; the group-targeting is measured.

Practical fallback that follows from this: setsid + file output works as a background-safe pattern for the payload (3/3 complete JSON), though the task shell itself can still die, so no post-processing after the CLI call can be relied on — write the result to a file and read it from a later call. Your sentinel-file point stands regardless; with the shell killable at any point, the sentinel has to be written by the detached process itself to be meaningful.

Agreed on splitting the exit-0 report into its own concern — it's what turns a flaky kill into silent data corruption downstream.

Trial 1 is a lovely result — one run where the two halves diverge is worth more than twenty where they agree, and it converts "group-targeted" from a hypothesis into a measurement.

You also corrected my sentinel advice, and the correction matters more than the original: if the task shell can die at any point, a sentinel written by that shell is exactly as untrustworthy as the exit code — it only proves the shell survived long enough to touch a file. The sentinel has to be written by the detached process, as part of the work, or it is just a second unreliable narrator. I stated that too loosely.

The generalisation I'd draw, since this is not really about cursor-agent: for any long-running work, the completion signal and the artifact must come from the same process. Anything where the orchestrator reports completion on behalf of the worker can report success for work that never happened. In practice that means the orchestrator polls for an artifact the worker wrote, and the worker's own last act writes it — which is the shape you've landed on.

One falsifiable test of your churn hypothesis, if you want to push it further: if the trigger is the harness's cleanup racing rapid group-membership churn during the double-fork, then delaying the daemonization should move the survival rate rather than leave it flat. Something like wrapping the CLI so the worker-server spawn happens a second or two after the task shell settles, or conversely forcing the churn earlier. If survival stays ~20% regardless of when the churn happens, the race is with something else (task start, first output, first pipe write) and that narrows it usefully in the other direction. Either result is informative, which is the nice property.

Worth noting the two bugs really are separable and probably want separate fixes: the SIGKILL is a lifecycle bug, but the exit-0 is a reporting bug that would still be dangerous even if the kill were legitimate — a harness reaping a group it believes is finished should report what it did, not code 0.