fix: load SAB's Claude channel as a development channel again

[SergioTCG]

Summary

Claude Code 2.1.296 silently stopped delivering SAB's MCP channel events. Its channel gate skips a server: entry passed through --channels. Each running session's MCP log records:

Channel notifications skipped: server slack-bridge is not on the approved channels allowlist (use --dangerously-load-development-channels for local dev)

Every running Claude session was affected. Slack prompts kept arriving through tmux paste, but the MCP channel fallback and the Slack permission relay were off.

Root cause

• September change: on 2 September (07da99e), SAB switched from --dangerously-load-development-channels to --channels server:slack-bridge. Claude 2.1.258's development-channel confirmation stranded headless starts.
• 2.1.296 channel gate (Iyt), for a server: entry:
  • loaded as a development channel → register;
  • otherwise → skip … not on the approved channels allowlist.
• 2.1.296 startup: the DevChannelsDialog ("WARNING: Loading development channels") appears on every launch that loads a development channel, with no persisted acceptance.

Fix

• scripts/run-session.sh loads SAB's private server with --dangerously-load-development-channels server:slack-bridge, the path CLAUDE.md prescribes.
• scripts/claude-consent.sh answers that dialog as strictly as the workspace-trust dialog:
  • it confirms only when the dialog lists exactly server:slack-bridge;
  • it confirms only once "I am using this for local development" is visibly selected, and moves up off a preselected Exit first;
  • any other or additional development channel is left for a human;
  • the watch window grows from 30 s to 60 s.
• The helper already runs for daemon-driven spawns and resumes (autoConsent), so new starts, resumes and provider switches are all covered.

Verification against real Claude Code 2.1.296

The rendered dialog:

WARNING: Loading development channels
…
Channels: server:slack-bridge
❯ 1. I am using this for local development
  2. Exit

The test used a fake daemon behind SAB's real channel server, with only its daemon address redirected:

Launch	Dialog	Channel message delivered
--channels server:slack-bridge (before)	none	no; the session shows the allowlist warnings
dev flag plus this helper, new session	accepted by the helper	yes: <channel source="slack-bridge" via="slack">…</channel>
dev flag plus this helper, --resume	accepted by the helper	yes

One cosmetic startup line remains: server:slack-bridge · no MCP server configured with that name. The CLI's display check only looks at settings-file MCP scopes, not --mcp-config, and the gate does not consult it.

Tests

• Claude runner loads its private channel server as a development channel: the runner passes the development-channel flag and not --channels.
• Claude consent helper confirms the development channel only for SAB's own server:
  • affirmative row selected → Enter;
  • Exit preselected → Up, Enter;
  • another channel, or an extra channel alongside SAB's → no keys.

Each mutation was applied on its own:

Mutation	Result
Back to --channels	red
Old blind Enter	red
Drop the exact-channel guard	red

Validation

• npm test: 592 pass. npm run check, npm run audit (0), node --check, Pi extension and shellcheck all pass.

Deployment notes

• No daemon restart is needed. The launcher and the consent helper are read on every session start or resume.
• Running sessions keep the skipped channel until they relaunch. A relaunch happens through /sab-restart, the /sab-update claude-code idle sweep, or a resume.

🤖 Generated with Claude Code

https://claude.ai/code/session_011Xs8AVBVrTGfpzUMiCQp2R