MCP elicitation dialog blocks scrolling the conversation behind it

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

While an MCP elicitation/create dialog is open, the terminal cannot be scrolled. Only the current screen is readable. Everything printed before the dialog — which is the material the dialog is asking me to make a decision about — is unreachable until I answer or cancel.

Elicitation dialogs are almost always a confirmation about something that was just described, so this is the one moment where the scrollback matters most. In my case an MCP server raises three approval gates: approve a design, approve a set of failing tests, accept a finished change. Each arrives right after Claude has printed the thing being approved, and that output goes out of reach exactly when I need to read it. The only options are to answer blind, or cancel, scroll up, read, and trigger it again.

What Should Happen?

The scrollback stays reachable while the dialog is open, the way it is during a normal turn. Re-reading what the dialog is about should not require dismissing the dialog.

Error Messages/Logs

No error is produced. Scrolling silently does nothing.

Steps to Reproduce

1. Save the minimal MCP server below as elicitation-scroll-repro.mjs (full source in Additional Information).
2. Register it: claude mcp add scroll-repro -- node /absolute/path/to/elicitation-scroll-repro.mjs
3. Start a session and ask for something that produces more than one screen of output.
4. Ask Claude to call the confirm tool. A dialog appears.
5. With the dialog open, scroll up with the mouse wheel. Nothing moves; the output from step 3 stays unreachable until the dialog is answered.

(Mouse wheel is what I tested. I did not try PgUp/PgDn or dragging the scrollbar, so I cannot say whether those behave differently.)

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.233 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

Relationship to #84602

#84602 asks for scrolling inside the elicitation prompt, so that a long message does not push the Accept/Decline options off-screen. This report is about the scrollback behind the dialog: the message here is three short lines and fits fine, but the conversation above it cannot be reached while the dialog is open.

The two reports disagree on a fact, which is worth resolving. #84602 states that "the main conversation and tool results scroll (PgUp/PgDn/mouse), but the elicitation prompt does not." On this machine the main conversation does not scroll with the mouse wheel while a dialog is open. That may be a difference in terminal, in the tui setting, or in version — or one of the two observations may be imprecise. If these turn out to be the same underlying issue, please close this as a duplicate; I filed it separately because the symptom and the fix are different.

Environment detail

Windows 11 Pro 10.0.26200, Node v24.12.0, tui: "fullscreen" in ~/.claude/settings.json.

I have not checked whether this also happens with a different tui setting, in another terminal emulator, or on macOS or Linux, so I cannot say how broad it is.

Why a server cannot work around this

Per the MCP specification (2025-06-18, client/elicitation), elicitation/create carries only message and requestedSchema, and the specification states that implementations are free to expose elicitation through any interface pattern — rendering and key handling belong entirely to the client. The only mitigation available to a server is to repeat the context inside the message text, which does not help when that context is a page of diff or test output.

<!-- PASTE THE REPRODUCTION SERVER HERE - see repro-server-block.md -->