--dangerously-load-development-channels should support skipping the confirmation dialog

Status Open

Maintainer reply None cached

Activity 7 comments · opened Apr 2, 2026

Problem

Every time I launch claude --dangerously-load-development-channels server:my-channel, the startup dialog forces me to manually select "I am using this for local development" before Claude Code proceeds. There's no way to persist this choice or skip it via a flag.

For workflows that frequently restart Claude Code with the same local channel server (e.g. a custom dispatch tool that launches multiple agents), this adds unnecessary friction — especially since the user has already opted in by typing --dangerously-load-development-channels in the first place.

Current behavior

Run claude --dangerously-load-development-channels server:my-channel
Dialog appears: "WARNING: Loading development channels"
Must manually select option 1 and press Enter
Claude Code starts

This happens on every launch, no persistent approval.

Expected behavior

One of:

A --yes flag (or similar) that auto-accepts the dialog: claude --dangerously-load-development-channels server:my-channel --yes
A persistent per-server approval stored in ~/.claude/settings.json or similar, so the dialog is shown once and remembered
Respect --dangerously-skip-permissions as an implicit acceptance (the user is already opting out of safety prompts)

Use case

I'm building a TUI that launches Claude Code agents in separate terminal windows with --dangerously-load-development-channels server:my-channel for coordination. Each agent launch requires manual intervention to click through the dialog, which breaks the automation flow.

server: entries can't use --channels (blocked by the plugin-only allowlist), so --dangerously-load-development-channels is the only option for local MCP channel servers.

Environment

Claude Code v2.1.90
Windows 11

View original on GitHub ↗

7 Comments

OhadRubin · 3 months ago

this is not stale. please solve this, don't make us patch the binary

OhadRubin · 3 months ago

tested on v2.1.126
https://gist.github.com/OhadRubin/0fda6190aa700696a16d961a980d0038

erudenko · 3 months ago

just want to joint to say that feature is needed

Aion-Code · 3 months ago

+1 — concrete impact: multi-agent orchestration with programmatic CC spawning (Master CC spawns named teammates via a custom MCP-channel daemon). Every spawn fires this prompt with no human at the keyboard to press Enter.

We've stacked Win32 workarounds today (~80 LOC) just to get through it:

wt.exe new-tab -Command "<text>" shredded our PS init line on ; → switched to -EncodedCommand UTF-16LE base64
Prompt blocked spawn → SendInput VK_RETURN after EnumWindows+GetWindowTextW HWND snap by unique title marker (homonym handoff would otherwise collide)
Single-spawn timing variance (. $PROFILE + launcher dot-source can push prompt-render to 4-7s) → 3 retries at 3.5s / 5.5s / 7.5s, accepting that any post-validation Enter hits the REPL as a no-op blank line

Any of these would delete the entire stack:

env var ANTHROPIC_DEV_CHANNELS_ACCEPT=1
settings.json key like developmentChannels.preApproved: ["server:foo"] (persistent, auditable)
--dangerously-skip-permissions honored as implicit acceptance

Multi-agent setups inherit this cost on every single spawn. Persistent or env-scoped acceptance would land big — happy to share more context on the design tradeoffs if useful.

davecazz · 2 months ago

++ could use this, perfectly legit use for this is a local orchestration flow that can push messages into an idling claude session. people are using tmux for the same kind of thing, but not everyone wants to use tmux. or agent teams

boukasa · 2 months ago

++ I also have this use case in all my claude code usage: our "interclaude" system sends logged messages between cc sessions so each session can remain context focused. To tell the other session "read your messages" a log file watcher sends a local channel ping, "clread." Every time terminals restart, every session must be manually attended to click the "yes."

fbserg · 1 month ago

Adding a concrete data point from running Claude Code as a long-lived headless Discord bot (systemd service, respawn loop, no TTY).

We attempted to switch from the plugin channel path to --dangerously-load-development-channels server:discord to route around the channels freeze in #36477. It is not viable headless: the flag prints a mandatory interactive gate at startup —

WARNING: Loading development channels
❯ 1. I am using this for local development
  2. Exit

— and --dangerously-skip-permissions does not bypass it (different prompt class). With no TTY the process hangs at this prompt permanently and never connects, so a headless deployment can never even evaluate the flag. We considered tmux send-keys to auto-dismiss and rejected it as fragile startup-timing hackery.

An env var or flag to pre-accept this confirmation (analogous to how other dangerous flags work non-interactively) would unblock headless use. Happy to test a fix — we have a reproducible always-on deployment.