Opening the agent list re-hosts the session without `--dangerously-load-development-channels`; channel wakes then stop silently

Version: 2.1.247 · Platform: macOS 26.2, arm64

Symptom

A session launched with --dangerously-load-development-channels <channel> loses its channel when the
agent list is opened (left-arrow). The conversation is re-hosted into a background session that is launched
without the flag, so channel events are silently dropped from then on.

The failure is invisible from inside the session: the channel's MCP server stays connected, reports no
error, and counts the wakes it emits — none of which reach the model. Nothing in the UI indicates the
channel is gone.

Reproduction

Reliable — 2 for 2 under observation, plus 2 earlier occurrences on the same day.

1. Launch: claude --dangerously-load-development-channels <channel> in a terminal.
2. Confirm the channel works (a wake arrives and is acted on).
3. Press left-arrow to open the agent list.

~/.claude/daemon.log, at the keypress — a daemon that was not running cold-starts and claims a spare
within ~250ms:

14:14:33.849Z [supervisor] ─── daemon start ─── version=2.1.247 pid=2824 origin=transient
14:14:33.917Z [bg] bg spare spawned host pid=2834
14:14:34.070Z [bg] bg claimed-spare 77fa0193 (slash)

Immediately after, in the session that had been in the foreground:

CLAUDE_JOB_DIR = ~/.claude/jobs/77fa0193      # was unset
parents        = bg-spare → bg-pty-host → claude daemon run --origin transient   # no tty

Evidence

1. The flag is absent from the re-hosted session and from its respawn template.

Foreground, before:

57475  ttys022  claude --dangerously-load-development-channels <channel> --resume

~/.claude/jobs/<id>/state.json → respawnFlags, after (verified across four separate jobs):
53 entries — --reply-on-resume, 24 mcp__computer-use__* grants, --permission-mode bypassPermissions,
--model — and never the channel flag. So no respawn can restore it.

2. The failure is silent. The channel server's own status, taken from inside the deaf session:

connected: true    lastError: null    reconnects: 0
wakesEmitted: 67   delivered: 0

67 wakes emitted by the server, none delivered to the model, nothing reported as wrong.

3. The original process survives as an unreachable orphan. It keeps the tty (S+) and its flag, but
its conversation is no longer displayed, cannot be typed into, and does not appear in the session list. The
only session visible or drivable is the background one — the one without the channel. Recovery requires
quitting and relaunching from a shell; there is no in-product path back.

4. No configuration can prevent it. The flag is per-launch by design and cannot be persisted via a
settings key or environment variable, so a session that loses it on re-host cannot regain it.

What does not trigger it

Each tested individually against a recorded baseline (daemon down, daemon.log line count noted, session
foreground). All produced zero new daemon-log lines and left the session foreground:

| Candidate | Result |
|---|---|
| Plugin slash commands (×4) | not a trigger |
| Listing sessions programmatically (agent-list data) | not a trigger |
| A message arriving mid-turn while the session is busy in a tool call | not a trigger |
| A message arriving during a long (4 min) blocking CPU-bound call | not a trigger |
| Remote Control messages (×2) | not a trigger |
| Ordinary Bash / MCP tool calls | not a trigger |
| Opening the agent list | daemon cold-start + spare claimed, ~250ms |

Enumeration being clean is the diagnostic result: listing sessions needs no daemon, so it is opening the
view that requires the current conversation to become daemon-hosted.

Note that every backgrounding event in daemon.log is labelled (slash), including the two confirmed to
be caused by the agent list — so that label identifies an internal dispatch path, not the user action.

Expected

Any one of these would resolve it:

1. Carry channel flags through re-hosting — include them in respawnFlags. Preferred.
2. Refuse to re-host a channel-enabled session, and say so, rather than dropping its channels silently.
3. At minimum, fail loudly — surface that the session was launched with channels the background session

does not have, and have the channel report itself disabled rather than connected: true with a rising
undelivered count. A visible failure is recoverable; this one is not.

Possibly related

• #77649 — flags wrongly inherited on forks, and --continue dropping permission mode. This is the

mirror image: a flag deliberately passed at launch being dropped.

• #73354 (closed as not planned) — session-id rotation and --fork-session --resume --reply-on-resume

re-hosting, which this rides on.