[Bug] Channel notifications dropped after session handoff to background processthat

Bug Description
Title: Channel notifications silently dropped after a session moves to a background process (development channel flag not inherited)

Summary

A session started with --dangerously-load-development-channels server:<name> receives channel notifications normally. After the session is handed off to a background process, the MCP channel server keeps working and keeps forwarding notifications. The session never receives them, and nothing reports an error.

Environment

• Claude Code 2.1.296
• macOS 27.0, zsh
• Model: Claude Opus 5.5
• channelsEnabled: true in user settings
• Channel server: a local MCP server, loaded via --dangerously-load-development-channels, that pushes GitHub CI and review events as <channel> notifications

Steps to reproduce

1. Start an interactive session with claude --dangerously-load-development-channels server:<channel-server> --chrome.
2. Confirm that channel notifications arrive in the session.
3. Let the session move to a background process. Here this happened at a fork (/fork): the original interactive process was parked, and the session continued in a pre-warmed spare started as claude bg-spare --bg-spare <claim socket>.
4. In the continued session, call a tool on the channel server. Tool calls work.
5. Trigger events that the channel server forwards as notifications.

Expected

The notifications appear in the continued session, as they did before the move. Or, if the session can't receive them, a visible error or warning appears.

Actual

• No notification reaches the session. The channel server's own log shows it forwarded six notifications to its client process, which is a child of the background process. The session transcript contains no channel entries after the handoff.
• Nothing reports a problem. Tool calls to the same server keep succeeding, so the session looks healthy

Evidence

• ~/.claude/sessions/<pid>.ocess shows "kind": "bg".Its command line has no channels flag.
• The parked original procely-load-development-channels server:<channel-server>. Its session file has "parkedJobId" pointing at the

continuing session.

• The Claude Code binary contains the messages "not in --channels list for this

session" and "is not on tlist (use--dangerously-load-development-channels for local dev)". This suggests the
notifications are being f couldn't capture the dropitself, because no debug log was written for the background session.

Likely cause (not confirmed)

Background or spare processes that take over a session don't inherit the parent session's --channels or --dt-channels flags, so thatsession's channel notifications are filtered out.
Suggested fix

• Carry the parent session's channel flags over to whatever process continues session.
• Or, when a session that can't receive notifications from a server gets one, show a warning instead of

Regression? Not known.

Environment Info

• Platform: darwin
• Terminal: xterm-256color
• Version: 2.1.296
• Feedback ID: 7a0af5f0-7d9b-4ddf-b56a-545cdcb98da8
• Written by Claude Code