›_ Claude Code Issues
Claude Code Issues / #47799

[BUG] claude login paste not working in code input field (regression in 2.1.105+)

Resolved 💬 16 comments Opened Apr 14, 2026 by dogyunhan Closed Apr 16, 2026
💡 Likely answer: A maintainer (mhegazy, contributor) responded on this thread — see the highlighted reply below.

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?

Description

Pasting the authentication code into the claude login prompt is broken starting from version 2.1.105. Both Ctrl+V and
right-click paste do nothing — the input field remains empty and the cursor doesn't move. Manual
character-by-character typing still works. Downgrading to 2.1.104 restores paste functionality immediately.

Environment

  • OS: Windows 11 + WSL2 (6.6.87.2-microsoft-standard-WSL2)
  • Terminal: Windows Terminal 1.23.20211.0
  • Shell: bash (xterm-256color)
  • Affected versions: 2.1.105, 2.1.107
  • Working version: 2.1.104

Steps to Reproduce

  1. Run claude login
  2. Complete browser authentication and copy the generated code
  3. Attempt to paste the code into the terminal prompt via Ctrl+V or right-click
  4. Nothing is entered — field stays empty

Expected Behavior

The copied code is pasted into the input field, same as in 2.1.104.

Actual Behavior

Both Ctrl+V and right-click paste are silently ignored. Manual typing is the only way to enter the code.

Additional Notes

  • Paste works normally everywhere else in the same terminal session (e.g. the main Claude Code conversation UI)
  • The issue is confirmed to be a Claude Code regression, not a terminal configuration issue:
  • Setting "bracketedPaste": false in Windows Terminal had no effect
  • WSL2 clipboard bridge (clip.exe) is functioning correctly — powershell.exe -command "Get-Clipboard" returns the

expected value from within WSL2

  • Switching the symlink at ~/.local/bin/claude back to 2.1.104 fixes the issue without any other changes

Workaround

Downgrade to 2.1.104 (binary is still present after auto-update)
ln -sf ~/.local/share/claude/versions/2.1.104 ~/.local/bin/claude

What Should Happen?

Claude should have users paste code for login

Error Messages/Logs

None

Steps to Reproduce

Just enter the '/login' in the latest version (2.1.105 or 2.1.107), and try to paste the code. It would not work.

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

2.1.104

Claude Code Version

2.1.107

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

WSL (Windows Subsystem for Linux)

Additional Information

_No response_

View original on GitHub ↗

16 Comments

Mikzas · 3 months ago

Same problem, thanks

github-actions[bot] · 3 months ago

Found 3 possible duplicate issues:

  1. https://github.com/anthropics/claude-code/issues/47725
  2. https://github.com/anthropics/claude-code/issues/47670
  3. https://github.com/anthropics/claude-code/issues/47734

This issue will be automatically closed as a duplicate in 3 days.

  • If your issue is a duplicate, please close it and 👍 the existing issue instead
  • To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

timoerlemans · 3 months ago

I also have this issue.

mickaeldanslenowhere · 3 months ago

Trick is to connect on a device that have the access to a browser and then copy credentials.json into the one that can't connect

You can even ask Claude to do it for you if you have access through ssh

aa-parky · 3 months ago

Reproduces on native macOS (iTerm2 + tmux) — not VM/WSL specific
Adding a data point: this also affects native macOS environments, confirming it's broader than VM or WSL setups.

Environment:

Claude Code: 2.1.107
OS: macOS (native, not VM)
Terminal: iTerm2 + tmux
Shell: zsh
Reproduced on: 5 separate machines simultaneously with no terminal config changes

Behaviour: Pasting the OAuth code into Paste code here if prompted > is silently swallowed. No error, prompt just hangs.

Workaround that works:
In iTerm2, use Edit → Paste Special → Paste Slowly and uncheck "Bracketed paste mode" before clicking Paste. This bypasses the issue by sending raw text without the \e[200~...\e[201~ escape sequences.
This suggests the regression is the auth input field no longer stripping bracketed paste escape sequences that terminals like iTerm2 automatically wrap pasted content with.

poof86 · 3 months ago

Same problem here, I can't paste the OAuth code even in the native Terminal.app
I created a simple PopClip extension that types your clipboard with keystrokes using an AppleScript. To get PopClip to show up in a terminal I have to double click.

install the extension named: TypeText.popclipext

tvvignesh · 3 months ago

Same issue here

tvvignesh · 3 months ago

This works for me in a headless server

Step 1: SSH in and start tmux, then run claude login:
  ssh <nameofvm>
  tmux new -s claude-login
  claude login

  It will show a URL — open that in your local browser and authorize. Copy the code you receive.

Step 2: From a new local terminal, send the code to the remote tmux session:

  ssh <nameofvm> "tmux send-keys -t claude-login 'PASTE_YOUR_CODE_HERE' Enter"

  Just replace PASTE_YOUR_CODE_HERE with the actual code (paste works on your local terminal). This makes tmux simulate typing the code into the waiting claude login prompt on the remote.

  That's it — claude login will receive the code and complete authentication. After that, you can tmux kill-session -t claude-login and use claude normally.
Lod3 · 3 months ago

Experiencing the same issue on v2.1.107.

Environment:

  • Windows 11 + WSL2
  • PowerShell 7 and Windows Terminal
  • Claude Code v2.1.107 (both WSL and Windows native installs)
  • Claude Max subscription

Symptoms:

  1. claude auth status correctly shows loggedIn: true with valid credentials
  2. claude -p "hello" works perfectly (non-interactive mode)
  3. Launching claude (interactive mode) always shows the onboarding wizard and auth flow
  4. At the "Paste code here if prompted >" prompt, there is no usable text input — Ctrl+V, right-click, Ctrl+Shift+V all fail to paste
  5. The interactive onboarding does not detect existing valid credentials, creating an auth loop

Additional detail:
The forceLoginMethod: "claudeai" setting in settings.json does not help — interactive mode still enters the auth flow. Copying credentials from WSL to the Windows .claude/.credentials.json also doesn't prevent the onboarding from appearing. The issue compounds two bugs: the paste regression and the onboarding not checking existing auth state.

---
Update: Downgrading to v2.1.104 via npm install -g @anthropic-ai/claude-code@2.1.104 fixed both the paste issue and the onboarding auth loop on the Windows side. This confirms the
regression was introduced in v2.1.105+.

Install method note: The initial install was via the PowerShell installer (irm https://claude.ai/install.ps1 | iex), which installs a standalone binary to ~\.local\bin\claude.exe. The
downgrade was done via npm. Not sure if the install method (standalone binary vs npm package) makes a difference for this bug, but worth noting.

tangix · 3 months ago

Same issue here but running in a docker sandbox so can't downgrade...
Also 

docker sandbox exec <project> claude auth login --claudeai

Shows the URL but don't allow paste either.

mhegazy contributor · 3 months ago

Duplicate of https://github.com/anthropics/claude-code/issues/47699

santosguerra · 3 months ago

Same problem, thanks

RonniPatel · 3 months ago

Same here.

Windows 11 - affecting terminal both inside and outside cursor.
Was working until 14/04 - where I upgraded to 2.1.107. Since upgraded further and can confirm it is still a problem in 2.1.109

dogyunhan · 3 months ago

The pasting issue for OAuth codes has been resolved in v2.1.109.

ashwin-ant collaborator · 3 months ago

This is a duplicate of #47699, which was fixed as of version 2.1.108.

---
_Generated by Claude Code_

github-actions[bot] · 2 months ago

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.