claude mcp login (and bare claude) fail with "stdin isn't a terminal" in a genuinely interactive Windows Terminal + PowerShell 7 session

Description

claude (bare, no subcommand) and claude mcp login <name> both immediately fail with:

stdin isn't a terminal, so authentication can't be completed here. Re-run in an
interactive terminal — e.g. `ssh -t` — and paste the redirect URL when prompted.

This happens in a genuinely interactive session — not piped, not redirected, not run from a script or scheduled task. claude mcp login <name> --no-browser fails identically before ever printing an authorization URL, so the failure happens at an upfront stdin/TTY check rather than during the browser-launch step.

Environment

• Claude Code: 2.1.205.0 (claude.exe, standalone compiled binary — FileVersionInfo.InternalName: bun)
• OS: Windows 11 Pro, build 10.0.26200
• Terminal: Windows Terminal (standalone app, not an editor-embedded terminal)
• Shell: PowerShell 7.6.2 (PSEdition: Core)
• No PowerShell profile exists (Test-Path $PROFILE → False)
• Get-Command claude -All resolves to exactly one binary, no function/alias/shim in the way

Steps to Reproduce

1. Open Windows Terminal, start a PowerShell 7 session (pwsh.exe)
2. Register any HTTP MCP server: claude mcp add --transport http test-server https://example.com/mcp
3. Run claude mcp login test-server
4. Observe immediate failure with the "stdin isn't a terminal" message — no browser opens, no URL is printed
5. Retry with claude mcp login test-server --no-browser — same immediate failure, before any authorization URL is printed
6. Separately, run bare claude (no args) in the same session — same "stdin isn't a terminal" error

Diagnostics ruling out environment causes

Run in the same session immediately before/after the failure:

PS> [Console]::IsInputRedirected
False

[Console]::IsInputRedirected is the standard .NET/Win32 check for whether stdin is genuinely redirected (piped, file-redirected, etc.), and it correctly reports False — this is a real, non-redirected console handle. This rules out:

• Piped/redirected input
• A PowerShell profile wrapping claude in a function (no profile exists)
• A shim/alias intercepting the call (Get-Command claude -All resolves to exactly one native binary)
• Legacy Windows PowerShell 5.1 ConPTY quirks (this is PowerShell 7 Core)

Since the .NET-level check disagrees with whatever check claude/Bun performs internally, the bug appears to be in how the CLI (or the Bun runtime it's compiled with) detects isTTY on stdin on Windows — most likely a GetConsoleMode/GetFileType check that behaves incorrectly under Windows Terminal's ConPTY layer specifically for this compiled binary, as opposed to the correct high-level Win32 API [Console]::IsInputRedirected uses.

Expected Behavior

claude mcp login (with or without --no-browser) and bare claude should recognize this as a real interactive terminal and proceed normally, matching what [Console]::IsInputRedirected reports.

Related but distinct issues

I searched before filing and found these, but none match this exact symptom:

• #23195 — different bug (FileIndex constructor crash outside a git directory, older Linux)
• #25021 — different bug (--print mode misdetected outside a git directory, Linux) — thematically similar ("wrong mode/TTY detection on an edge case") but different platform and different trigger condition (our directory is a real git repo)
• #26874, #57246, #81336 — all about the main account claude login OAuth flow failing on headless/SSH sessions with a malformed scope parameter — a different code path from claude mcp login