[BUG] macOS: attaching to a previous-day background job via claude agents kills the worker — "SIGKILL (137) before init" / resume-guard respawn loop

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet (closest: #60254 — non-deterministic exit 1 before init on fresh claims, closed; #72719 — crashes under memory pressure; #72221 — supervisor signal war with concurrent agents. This report is a different trigger: reattaching previous-day jobs, and the worker dies by signal 9, not exit 1.)
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code

What's wrong?

Attaching to a background job created on a previous day via claude agents (FleetView) reliably kills the freshly spawned spare worker. The underlying session is always intact — direct claude --resume <session-id> works every time — but the FleetView attach path marks the job failed/red.

Two failure signatures observed on consecutive days, same trigger:

Variant A — SIGKILL (137) before init (job created 2026-07-05 by CLI 2.1.201, reattached 2026-07-06):

[2026-07-06T05:44:01.012Z] [bg] bg claimed-spare c5b0753b (fleet)
[2026-07-06T05:44:01.015Z] [bg] bg spare spawned host pid=41533
[2026-07-06T05:44:15.764Z] [bg] bg settled c5b0753b (crashed)

~/.claude/jobs/c5b0753b/state.json afterwards:

{
  "state": "failed",
  "detail": "SIGKILL (137) before init",
  "cliVersion": "2.1.201",
  "respawnFlags": ["--reply-on-resume", "--effort", "high", "--permission-mode", "auto", "--model", "claude-opus-4-8"]
}

The worker dies ~14s after the claim, before completing the daemon init handshake. Worker stderr (/tmp/cc-daemon-502/<id>/spare/*.err) is empty — consistent with SIGKILL.

Variant B — resume-guard self-deadlock respawn loop (job created 2026-06-22 by CLI 2.1.185, reattached 2026-07-05 under 2.1.201): the daemon claims a spare for the finished job, the worker's --resume hits the "session is currently running as a background agent" guard — apparently tripped by the claim the daemon itself just made — and exits, so the daemon respawns it in a loop until it gives up:

Sess05d9e08e-… is currently running as a background agent (bg). Use `claude agents`
to find and attach to it, or add --fork-session to branch off a copy.
[worker crashed (exit 1 — exit_with_message) — respawning…]

[2026-07-05T07:04:26.427Z] [bg] bg claimed-spare 05d9e08e (fleet)
[2026-07-05T07:04:26.430Z] [bg] bg spare spawned host pid=19707
[2026-07-05T07:04:45.257Z] [bg] bg settled 05d9e08e (crashed)

Ruled out (investigated before filing)

• Gatekeeper / code signing — spares are spawned directly from ~/.local/share/claude/versions/2.1.201 (valid signature, verified with codesign --verify), not through the unsealed ClaudeCode.app bundle of #70647; confirmed via live process tree (--bg-pty-host / --bg-spare children of the daemon).
• Memory / jetsam — no JetsamEvent names any claude process, 66% RAM free at crash time, transcripts are small (<1 MB).
• Security software — no EDR/endpoint agent running (systemextensionsctl list shows only Karabiner + OBS).
• Supervisor/worker version skew — daemon supervisor and workers both 2.1.201 at the time of Variant A.

Whatever sends the signal is inside the daemon stack itself (init-deadline kill?). daemon.log shows 31 of 299 job settlements as (crashed) since 2026-06-13, clustering from 06-30 onward.

Environment

• Claude Code 2.1.201 (native installer, autoUpdates on; affected job records created by 2.1.185 and 2.1.201)
• macOS 26.5.1 (25F80), Apple Silicon (arm64)
• Shell: zsh

Steps to reproduce

1. Start a background agent (&-prompt or fleet) and let it finish or block on user input.
2. Exit; wait until the next day (daemon has since recycled/restarted).
3. claude agents → select the old job to attach.
4. Worker dies: SIGKILL (137) before init (or the Variant B respawn loop); job turns red/failed.

Expected

Attaching to an idle finished/blocked background job should reattach (or cleanly hand off to a resume), matching the behavior of claude --resume <session-id>, which succeeds for the same sessions.

Workaround

cd <project> && claude --resume <full-session-id> always works; if a job crash-loops in FleetView, mv ~/.claude/jobs/<short-id> ~/.claude/backups/ stops the retries.