claude-code - 💡(How to fix) Fix OAuth login on headless EC2: code paste broken after recent update [1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#47994Fetched 2026-04-15 06:36:24
View on GitHub
Comments
0
Participants
1
Timeline
4
Reactions
5
Author
Participants
Timeline (top)
labeled ×4

Root Cause

Each claude auth login generates a unique code_challenge. The OAuth code returned after authorization is cryptographically bound to that specific challenge. This means:

  • You MUST use the code with the SAME session that generated the URL
  • Starting a new claude auth login invalidates all previous codes
  • The tmux approach works because send-keys types into the SAME process

Fix Action

Fix / Workaround

Current workaround

Using tmux send-keys to deliver the code into the same process that generated the PKCE challenge:

Code Example

# Start login in tmux
tmux new-session -d -s login 'bash -lc "claude auth login" 2>&1 | tee /tmp/tmux_login.log'
sleep 6
cat /tmp/tmux_login.log
# Open the URL in local browser, get the code, then:
tmux send-keys -t login "CODE_HERE" Enter
RAW_BUFFERClick to expand / collapse

Problem

After a recent Claude CLI update, the OAuth login flow on headless EC2 instances no longer allows reliable copy-paste of the OAuth code.

Environment

  • Ubuntu 24.04 on EC2 (headless, no browser)
  • SSH from Windows terminal
  • Claude CLI (latest)

What broke

  1. claude auth login prints an OAuth URL and prompts for the code
  2. After authorizing in a local browser, the returned code (format: XXXXXX#YYYYYY) cannot be pasted back reliably:
    • Ctrl+V doesn't work in SSH terminals on Windows
    • The # character in OAuth codes gets interpreted as a shell comment
    • Right-click paste is unreliable
    • Piping via echo "code" | claude auth login opens a new PKCE flow, ignoring the piped input
    • expect cannot detect the raw terminal > prompt

Current workaround

Using tmux send-keys to deliver the code into the same process that generated the PKCE challenge:

# Start login in tmux
tmux new-session -d -s login 'bash -lc "claude auth login" 2>&1 | tee /tmp/tmux_login.log'
sleep 6
cat /tmp/tmux_login.log
# Open the URL in local browser, get the code, then:
tmux send-keys -t login "CODE_HERE" Enter

This works but is cumbersome for production environments with multiple EC2 instances.

Suggestion

Consider one of:

  • A --code flag: claude auth login --code <oauth-code> (non-interactive)
  • A file-based flow: claude auth login --code-file /tmp/oauth-code.txt
  • Support for piped stdin: echo "code" | claude auth login
  • A device-code flow that doesn't require pasting back into the CLI

What Does NOT Work

MethodWhy It Fails
Copying credentials from local machineOAuth tokens are machine-bound
Piping stdin via echo "code" | claude auth loginCLI opens a new OAuth flow
expect with prompt matchingRaw terminal input undetectable
Starting multiple login attemptsEach creates new PKCE challenge
Ctrl+V / right-click paste in SSHUnreliable on Windows; # in codes breaks

Key Insight: PKCE Challenge Binding

Each claude auth login generates a unique code_challenge. The OAuth code returned after authorization is cryptographically bound to that specific challenge. This means:

  • You MUST use the code with the SAME session that generated the URL
  • Starting a new claude auth login invalidates all previous codes
  • The tmux approach works because send-keys types into the SAME process

extent analysis

TL;DR

Implement a non-interactive authentication method, such as a --code flag or file-based flow, to bypass the unreliable copy-paste of OAuth codes in headless EC2 instances.

Guidance

  • Consider adding a --code flag to the claude auth login command to allow for non-interactive authentication, e.g., claude auth login --code <oauth-code>.
  • Explore a file-based flow where the OAuth code can be written to a file and then passed to the claude auth login command, e.g., claude auth login --code-file /tmp/oauth-code.txt.
  • Investigate supporting piped stdin to allow for automated authentication, e.g., echo "code" | claude auth login.
  • Evaluate the feasibility of implementing a device-code flow that eliminates the need for pasting the OAuth code back into the CLI.

Example

# Example of a potential --code flag implementation
claude auth login --code XXXXXX#YYYYYY

# Example of a potential file-based flow implementation
echo "XXXXXX#YYYYYY" > /tmp/oauth-code.txt
claude auth login --code-file /tmp/oauth-code.txt

Notes

The current workaround using tmux send-keys is cumbersome and may not be suitable for production environments. A more robust solution is needed to address the issue of unreliable copy-paste of OAuth codes in headless EC2 instances.

Recommendation

Apply a workaround, such as the proposed --code flag or file-based flow, to bypass the unreliable copy-paste of OAuth codes. This will provide a more reliable and automated authentication process for headless EC2 instances.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING