[BUG] claude.ai MCP connector "needs auth" banner is non-dismissible and wedges plugin message-injection in long-lived sessions

Summary

In a long-lived (headless/daemonized) Claude Code session that uses a plugin to inject messages into the running session, a claude.ai MCP connector that lands in a needs-auth state on cold start raises a persistent TUI banner that has no auto-dismiss path. While that banner is up, the plugin's message-injection pipeline is wedged — injected messages are no longer processed — and the session stays stuck indefinitely until the process is force-restarted. There is no programmatic or timed way to clear the banner.

Environment

• Claude Code 2.1.90
• macOS 26.5.1 (build 25F80)
• Long-lived session driven by a message-injection plugin (Claude Code Channels, used here as a Telegram bridge)
• One or more claude.ai MCP connectors configured

Steps to reproduce

1. Start a long-lived Claude Code session that relies on a plugin injecting user turns into the session (vs. interactive typing).
2. Have at least one claude.ai MCP connector configured.
3. On cold start, the connector hits a probe race and resolves to needs-auth / "connectors need authentication."
4. A connector banner (strings like claude.ai connector + needs auth / connectors need…) renders and stays up.

Expected

• The connector-auth banner is dismissible — auto-expires after a timeout, OR exposes a programmatic/keypress dismiss — and a single connector in needs-auth does not block the message-injection path. A degraded connector should fail soft, not freeze the whole session's input pipeline.

Actual

• The banner persists with no dismiss path.
• Plugin message-injection is wedged for the duration — injected turns are silently dropped (they queue as "pending" but never process).
• Only a full process restart clears it.

Impact

This makes unattended/automation use of Claude Code fragile: a transient connector probe race on startup can silently take a long-running session offline with no self-recovery. Because the banner has no auto-dismiss, the session can't recover on its own.

Current workaround

We run an external cron healthcheck that tails the session log, counts co-occurring claude.ai connector + needs auth/connectors need strings, and — when combined with a non-zero pending-message backlog — classifies it as a "connector-banner zombie" and force-restarts the session via a rollover script. This works but is a brittle log-scraping heuristic around what should be a soft-failing, dismissible banner.

Suggested fixes (any one would help)

1. Give the connector-auth banner an auto-dismiss timeout and/or a programmatic dismiss.
2. Don't let a needs-auth connector block the message-injection / input pipeline — isolate connector state from session input.
3. Surface connector-auth as a non-blocking notice rather than a modal-style persistent banner in non-interactive sessions.