[BUG] /config reload leaves the interactive settings dialog open; subsequent typed input is captured by the dialog's search box, not submitted as a prompt

What I expected

After typing /config reload to pick up updated ~/.claude/settings.json, the dialog should apply the change and return to the normal ❯ prompt — same as how /clear or /exit close cleanly.

What actually happens

/config reload enters the interactive /config settings dialog (Status / Config / Usage / Stats tabs) and stays there waiting for input. There is no visible "applied, dismissing" step. The dialog footer reads Space to change · Enter to save · / to search · Esc to cancel.

If anything is typed into the pane after that (literal keystrokes, e.g. via tmux send-keys), it is captured by the dialog's / (search) field instead of being submitted as a new user prompt. The agent never sees those characters.

Example pane state after /config reload followed by a tmux send-keys -l "v3.31.2 RELEASED — fixes …":

╭───────────────────────────────────────────────────────────────────╮
│ ⌕ v3.31.2 RELEASED — fixes …                                      │
╰───────────────────────────────────────────────────────────────────╯

No settings match "v3.31.2 RELEASED — fixes …"

Space to change · Enter to save · / to search · Esc to cancel

The agent is idle and unreached. The user (or another tool) has to send Esc first to dismiss the dialog before the agent can receive any new input.

Reproducer

1. Open a Claude Code session in tmux. Note the pane id (e.g. mysess:0.0).
2. From another shell:

``bash
tmux send-keys -t mysess:0.0 -l "/config reload"
tmux send-keys -t mysess:0.0 Enter
sleep 1
tmux send-keys -t mysess:0.0 -l "hello agent"
tmux send-keys -t mysess:0.0 Enter
tmux capture-pane -p -t mysess:0.0 -S -20 | tail -10
``

1. Observe: pane shows No settings match "hello agent" instead of the agent processing "hello agent".
2. Send Esc:

``bash
tmux send-keys -t mysess:0.0 Escape
``

1. Subsequent sends now reach the agent normally.

Why it matters

Mesh / agent-to-agent coordination patterns (e.g. agent-mesh's notify-pane, or any cron / hook / sibling-agent driver that delivers messages via tmux send-keys) treat the prompt as an inbox. A fleet-wide tmux send-keys "/config reload" to propagate a settings change — perfectly idiomatic when you've just rolled out a ~/.claude/settings.json update via scp — leaves every recipient pane stuck in the /config dialog. Notifications fired after that propagation are silently lost: the agents never see them, only the dialog's "No settings match" line records the keystrokes.

We hit this end-to-end during a real fleet rollout (HeliosDB-Nano v3.31.2 release announcement to 16 peer Claude panes across 3 hosts on 2026-05-22). The post-/config reload release notification to the dm26[general:1] pane was eaten; recovery required diagnosing the issue, sending Esc manually, and re-firing the notification.

Proposed fix

/config reload should be a "fire-and-forget" applier, not a dialog opener:

• Apply the new settings file
• Show a one-line confirmation in the transcript (e.g. Config reloaded from /home/user/.claude/settings.json — 3 keys changed)
• Return to the ❯ prompt

The interactive dialog should remain reachable via the bare /config form (no args). This matches the way /permissions (interactive) and /permissions show (one-shot output) split today.

Alternative if the dialog must open: it should auto-dismiss after a short timeout or after the apply step, so the steady state is a clean prompt.

Workaround until then

Always send Escape before tmux send-keys-based notifications when there's any chance a recipient pane was hit with /config reload (or any other modal-opening slash command) recently. Mesh tooling can prepend Escape defensively to every notification's send sequence — single extra round-trip, idempotent on already-clear input boxes.

Related

• agent-mesh local fix tracker: https://github.com/danimoya/agent-mesh/issues/2

Environment

• Claude Code (CLI) — claude-opus-4-7[1m], currently running.
• Linux, tmux 3.x, bash.
• Observed in this session on 2026-05-22 (reproduced multiple times).