[Bug] MCP authentication prompt hangs when pressing enter to continue

same here, stuck, no response after pressing Enter

<img width="506" height="220" alt="Image" src="https://github.com/user-attachments/assets/04a5f1b6-5fd6-47e8-b3bd-03f60d69ee5b" />

Draft bug report: MCP OAuth "Press Enter to continue" ignores keyboard input

Intended as a follow-up comment on:

• https://github.com/anthropics/claude-code/issues/42707 (primary)
• https://github.com/anthropics/claude-code/issues/45875 (duplicate family)

---

Summary

After completing OAuth in the browser for a remote MCP server, the "Press Enter to continue" modal in Claude Code does not respond to Enter, Esc, or any other key. Ctrl+C is the only escape. Reproduces in iTerm2 and Terminal.app. Byte-level packet capture shows Enter is being delivered to Claude Code as \r (0x0D) — the process receives it and ignores it. The bug is not in the host terminal.

Environment

• Claude Code: 2.1.107 (current latest as of 2026-04-14)
• Platform: macOS (darwin)
• MCP server: Kinobi (claude.ai/kite-style remote OAuth)
• Terminals reproduced in: iTerm2 3.6.8, Terminal.app

Reproduction

1. claude --dangerously-skip-permissions
2. /mcp → select Kinobi → follow OAuth link to browser
3. Complete auth in browser
4. Return to terminal — modal shows "Press Enter to continue"
5. Press Enter — nothing happens
6. Press Esc — nothing happens
7. Only Ctrl+C escapes

Evidence: bytes reach the process

I captured the raw bytes flowing from iTerm2 into Claude Code's controlling pty using a small pty-wrapper that forwards stdin to the child while logging every byte with a timestamp. The capture point sits between the terminal emulator and Claude Code.

iTerm2 capture

Timestamps are unix-seconds-with-ms, relative-zeroed at 1776173545. Annotations added for clarity.

+0.52    IN hex=1b503e7c695465726d3220332e362e381b5c   # DCS reply: "iTerm2 3.6.8" (answer to DA2)
+0.53    IN hex=1b5b3f36343b313b323b343b363b31373b... # CSI ?64;1;2;4;6;17;18;21;22;52c (DA)
+2.92    IN hex=1b5b4f                                 # focus-out  (user clicked browser)
+19.71   IN hex=1b5b49                                 # focus-in   (user returned after OAuth)
+22.90   IN hex=2f  6d  63  70                         # "/mcp"
+23.90   IN hex=0d                                     # Enter — opens the MCP menu (works)
+24.79,+24.97,+25.13  hex=1b5b42                       # Down arrow × 3
+25.48   IN hex=0d                                     # Enter — selects Kinobi, opens browser
+26.26   IN hex=0d                                     # (extra Enter while modal still loading)
+26.38   IN hex=1b5b4f                                 # focus-out (browser auth)
+27.45   IN hex=1b5b49                                 # focus-in  (user returned)
+35.56   IN hex=0d                                     # Enter on "Press Enter to continue" — IGNORED
+39.02   IN hex=0d                                     # Enter                                  — IGNORED
+39.51   IN hex=0d                                     # Enter                                  — IGNORED
+39.78   IN hex=0d                                     # Enter                                  — IGNORED
+40.26   IN hex=1b                                     # Esc                                    — IGNORED
+40.74   IN hex=1b                                     # Esc                                    — IGNORED
+41.32   IN hex=1b                                     # Esc                                    — IGNORED
+63.20   IN hex=1b5b32373b353b39397e                   # CSI 27;5;99~ (Ctrl+C via modifyOtherKeys)  — escape

The bytes Claude Code is receiving for "Enter" are 0x0D — a plain carriage return, exactly what a POSIX terminal delivers for Enter in raw mode. Esc is 0x1B. Focus-reporting (CSI O / CSI I) was correctly emitted around the OAuth redirect.

Native Claude Code installed via npm and run directly inside iTerm2 (no wrapper, no intermediate pty) reproduces the same hang. The OAuth-ignore-Enter behavior is independent of the host terminal.

What this rules out

• ❌ Kitty keyboard protocol divergence — iTerm sent plain \r, same as every other terminal tested.
• ❌ ICRNL / raw-mode translation — bytes verified at the pty master fd.
• ❌ Terminal identity gating — TERM_PROGRAM, DA/DA2 responses all present in iTerm capture.
• ❌ Focus reporting — CSI [O / CSI [I were delivered correctly around OAuth.
• ❌ Third-party terminal bugs — reproduced in native iTerm2 and Terminal.app.

Hypotheses

The process reads \r but the modal's input handler does not advance. Likely causes:

1. The Ink component rendering "Press Enter to continue" is not mounted / not the active useInput consumer when the OAuth callback returns. The browser redirect might complete after the modal has been rendered but before the input hook runs (race between the OAuth HTTP server's onComplete and the Ink focus stack).
2. The OAuth callback server's process.stdin.resume() or equivalent is not being called, leaving stdin paused at the kernel level — but this would also block Ctrl+C, which does work, so less likely.
3. State-machine bug: the modal's internal state is stuck in a "waiting for OAuth" phase and the "OAuth complete, await keypress" transition never fires, so keypresses match no handler.

Reproducibility

100% — hits every time on this machine, and separately reported by multiple users on #42707 / #45875 / #45268 / #45220.

Ask

Please prioritize — every MCP server using OAuth through the claude.ai proxy is currently unusable, and there is no keyboard-level workaround. The byte-level evidence here should make the fix localized to the Ink prompt's input hook around the OAuth-complete transition.

Happy to share raw capture logs if useful.

Pressing tab first then enter works for me

Same issue as of 04/16/2026

Environment

• Claude Code v2.1.111
• Platform: macOS (Darwin 24.3.0)
• Shell: zsh

Pressing tab first then enter works for me

Yoo this works! I wonder why though.

Reproduced on macOS with Claude Code 2.1.118 inside WezTerm (first WezTerm report in this thread, confirming the bug is terminal-independent).

Adding a few observations not captured in existing comments:

1. Sleep-crossing trigger: in my case the hang did not happen immediately after the browser auth returned. The /login session sat on "Press Enter to continue…", the laptop slept for several hours, and the modal was unresponsive on wake. Consistent with an Ink input-hook subscription being lost across long pauses.

1. Parallel /login in multiple panes: I had /login running concurrently in two WezTerm panes (multi-account switching). Both ended up stuck on the same modal. Not an Agent Teams setup — plain multi-pane Claude Code.

1. Process-level state of a hung instance:

• ps state: S+ (sleeping, foreground), main thread parked in kevent64 — normal idle wait, not a spin
• stty -a on the controlling pty: -icanon -isig -iexten -echo (standard raw mode), identical to healthy panes
• fds 0/1/2 still pointing at the pty; pty master write offset ~2 MB (process wrote output but is no longer reading)
• clean SIGTERM, no orphaned threads

1. External input bypass also fails: wezterm cli send-text --pane-id <id> $'\r' writes \r directly to the pty master, bypassing the GUI keyboard input path. No reaction — corroborates the byte-capture evidence above that the bytes reach the process but the in-process input handler drops them.

Happy to share more if useful.