[BUG] Background daemon respawn crashes "exit 1 before init" when Fleet view reattaches an idle session

What's Wrong?

A session that is idle (state shown as "needs input" in the Fleet/agent-view dashboard) flips to "failed" when the background daemon tries to respawn/reattach it. The respawned worker process crashes immediately with exit 1 before init, before any normal Claude Code startup logging appears. This happens in both cmux and a plain macOS Terminal.app session, so it isn't tied to a specific terminal emulator — it's the daemon's background respawn path.

The job's own state.json (~/.claude/jobs/<id>/state.json) records the failure, but the captured error detail is truncated/corrupted:

exit 1 before init — …/root/chunk-wvb0gwjm.js:15:15300) at VNt (/$bunfs/root/chunk-y9287e05.js:12:355) at async GOo (/$bunfs/root/chunk-hgqaw23a.js:22:68) at async Mt (/$bunfs/root/cli:15:291) Bun v1.4.3 (macOS arm64) ^[[I

Note the stray terminal escape sequence (^[[I, CSI "focus-in") embedded at the end of the captured message — the daemon's stderr capture for the fresh-spawned worker appears to be mixing in unrelated terminal I/O, not just missing data.

--debug-file output shows the daemon repeatedly reporting a "successful" respawn immediately followed by the worker being dead:

[DEBUG] [PERF:respawn] b0f1fdaa: total=99ms probe=7ms kill=0ms (ceremony skipped) wait=0ms transcript=36ms dispatch=54ms ok=true
[DEBUG] [FV-attach] respawnJob b0f1fdaa: ok=true alive=false err=

ok=true alongside alive=false suggests the daemon isn't detecting the crash as a respawn failure on the first attempt — it keeps retrying a respawn that fails every time until the job is finally marked failed.

This looks closely related to #90149 ("Background daemon: fresh-spawned (non-spare) --bg workers crash 'exit N before init' 100% of the time"), which described two trigger conditions (same-second --bg dispatch race, cold daemon start). This report adds a third: a simple idle-session reattach from the Fleet view, with no concurrent dispatches and no cold start involved. That issue has seen no activity in about a month, so filing separately with this additional trigger and the corrupted-detail evidence in case it helps unstick it.

What Should Happen?

An idle session showing "needs input" in the Fleet view should reattach cleanly when the daemon respawns its worker, without crashing. If the daemon detects a respawn is going to fail, it should stop retrying immediately and surface a clear, uncorrupted error rather than flipping the job to "failed" after multiple silently-failing "successful" respawn attempts.

Error Messages/Logs

2026-09-24T16:28:53.497Z [DEBUG] [PERF:respawn] b0f1fdaa: total=140ms probe=3ms kill=0ms (ceremony skipped) wait=0ms transcript=28ms dispatch=108ms ok=true
2026-09-24T16:28:53.505Z [DEBUG] [FV-attach] respawnJob b0f1fdaa: ok=true alive=false err=
2026-09-24T16:28:53.505Z [DEBUG] [PERF:bg-attach-start]
2026-09-24T16:28:53.526Z [DEBUG] [bg-attach] worker gone on reconnect probe short=b0f1fdaa — settled while attached
...
2026-09-24T16:28:53.390Z [DEBUG] bg: socket dispatch fell through (EAUTH), using file path

state.json:
{
  "state": "failed",
  "detail": "exit 1 before init — …/root/chunk-wvb0gwjm.js:15:15300) at VNt (/$bunfs/root/chunk-y9287e05.js:12:355) at async GOo (/$bunfs/root/chunk-hgqaw23a.js:22:68) at async Mt (/$bunfs/root/cli:15:291) Bun v1.4.3 (macOS arm64) ^[[I",
  "tempo": "idle",
  "template": "claude",
  "respawnFlags": ["--agent", "claude"],
  "backend": "daemon"
}

Steps to Reproduce

1. Open a terminal (Terminal.app or cmux both reproduce this) and run claude in a project directory to start a new session.
2. Send a message and let Claude respond normally — the foreground session works fine.
3. Leave the session idle (don't send further input) until it shows as "needs input" in the Fleet/agent-view dashboard.
4. Return to the Fleet view and open/reattach that session.
5. The daemon respawns the worker in the background; the session's status flips from "needs input" to "failed".
6. Inspect ~/.claude/jobs/<job-id>/state.json — state is "failed" with a detail field containing exit 1 before init and the Bun stack trace shown above.

Note: chatting live in the foreground session works without issue — the crash is specific to the daemon's background respawn/reattach path, not the interactive session itself.

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Claude Code Version

2.1.281 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Other (reproduces in both Terminal.app and cmux)

Additional Information

• Also reproduces inside cmux, a third-party terminal app with its own Claude Code session-management integration — but since it reproduces identically in plain Terminal.app, the root cause is in Claude Code's daemon, not cmux.
• claude doctor reports no installation issues; claude update reports already on the latest version. Config/session directories were recently restored from a backup after an unrelated cmux crash, but the respawn failure reproduces on newly created sessions too, not just restored ones — so this isn't specific to restored state.
• Happy to attach the full --debug-file log or additional state.json samples from other failed jobs if useful.