--dangerously-load-development-channels is not propagated to the session process on daemon fork-resume (channel notifications silently dropped)

Summary

When an interactive terminal frontend launched with --dangerously-load-development-channels server:<name> continues a conversation through the daemon/pty-host architecture, the flag is not propagated to the spawned session process. The session's harness then rejects every channel notification from that MCP server with:

Channel notifications skipped: server <name> not in --channels list for this session

The MCP server itself works (it connects, its tools are callable, and its notifications/claude/channel messages reach the harness — visible in ~/.cache/claude-cli-nodejs/<project>/mcp-logs-<name>/*.jsonl), but nothing ever surfaces as a <channel> tag in the conversation. From the user's perspective the channel just goes silent, with no error anywhere in the UI.

Environment

• Claude Code 2.1.210 / 2.1.211, Linux (Debian WSL2)
• MCP server registered via ~/.claude.json mcpServers (stdio), delivering events with the experimental claude/channel capability

Repro

1. Register a stdio MCP server that emits notifications/claude/channel (e.g. bridging a message queue).
2. Start an interactive session: claude --dangerously-load-development-channels server:<name> — channel events surface correctly.
3. Continue the conversation such that the CLI hosts the session via the daemon (claude daemon run --origin transient … spawning claude bg-pty-host … -- claude --session-id … --fork-session --resume …).
4. Inspect the spawned session process: the flag is absent from its argv; its mcp-log shows Channel notifications skipped: server <name> not in --channels list for this session.

Expected

The channels allowlist granted to the frontend should follow the conversation across daemon fork-resume — or at minimum the drop should be surfaced to the user, since the frontend explicitly opted in.

Notes

• The frontend process retains the flag; only the daemon-spawned session process loses it.
• The spawned session also receives the "Background Session" system-prompt section even though the user is attached to it via the frontend's pty, which is what led us to debug this in the first place.

Happy to provide fuller logs if useful.