[FEATURE] Desktop app SSH sessions should use CLI-style credential resolution, not OAuth-only Remote Control auth (3P providers & LLM gateways)

Resolved 💬 3 comments Opened May 9, 2026 by pelopina6 Closed May 13, 2026

Preflight Checklist

  • [x] I have searched existing requests and this feature hasn't been requested yet
  • [x] This is a single feature request (not multiple features)

Problem Statement

When initiating an SSH session from the Claude Code Desktop app, authentication is currently gated behind Anthropic OAuth — the same path as Remote Control dispatch sessions. This is the wrong credential resolution strategy for SSH, and completely breaks users on 3P mode (Bedrock/Vertex/Foundry) and LLM gateway setups.
The problem
The docs state:

"Claude Desktop and remote sessions use OAuth exclusively and do not call apiKeyHelper or read API key environment variables."

This conflates two fundamentally different session types:

Remote Control / dispatch — Anthropic-managed session coordination. OAuth makes sense here since it's your infrastructure.
SSH — just a terminal on a remote machine. There is no session handshake with Anthropic's servers. Auth should behave identically to a local CLI session.

This breaks three categories of users:

3P cloud providers (CLAUDE_CODE_USE_BEDROCK / CLAUDE_CODE_USE_VERTEX / CLAUDE_CODE_USE_FOUNDRY) — these users have no Anthropic OAuth identity at all.
LLM gateways (ANTHROPIC_AUTH_TOKEN as a bearer token) — orgs routing through an internal gateway have no path to authenticate SSH sessions from the Desktop app.
Direct API key users (ANTHROPIC_API_KEY) — bypassed entirely in Desktop SSH context.

Expected behavior
SSH sessions launched from the Desktop app should resolve credentials using the same priority order as CLI:

Cloud provider credentials (CLAUDE_CODE_USE_BEDROCK / CLAUDE_CODE_USE_VERTEX / CLAUDE_CODE_USE_FOUNDRY)
ANTHROPIC_AUTH_TOKEN (LLM gateway bearer token)
ANTHROPIC_API_KEY
apiKeyHelper
OAuth (fallback)

Related issues

#44028 — OAuth/Keychain inaccessible over SSH on macOS
#44089 — VS Code Remote SSH re-login due to Keychain inaccessibility
#49136 — SSH-agent-style credential forwarding

https://github.com/anthropics/claude-code/issues/newYou said: they are asking for proposed solution .they are asking for proposed solution . what should I say there ?9:54 AMClaude responded: Here's a proposed solution section you can add:Here's a proposed solution section you can add:

Proposed Solution
The Desktop app should detect the session type at launch and choose the credential resolution strategy accordingly:

If the session is a Remote Control / dispatch session → keep OAuth-only (current behavior, correct)
If the session is an SSH session → use CLI-style credential resolution chain (cloud provider creds → ANTHROPIC_AUTH_TOKEN → ANTHROPIC_API_KEY → apiKeyHelper → OAuth fallback)

Concretely, this means the SSH session bootstrap should:

Read CLAUDE_CODE_USE_BEDROCK / CLAUDE_CODE_USE_VERTEX / CLAUDE_CODE_USE_FOUNDRY from the remote environment
Call apiKeyHelper if configured
Read ANTHROPIC_AUTH_TOKEN / ANTHROPIC_API_KEY from the remote environment
Only fall back to OAuth if none of the above are present

This is already the correct behavior for CLI sessions — SSH sessions in the Desktop app should be treated as CLI sessions on a remote machine, not as Remote Control sessions.

Proposed Solution

The Desktop app should detect the session type at launch and choose the credential resolution strategy accordingly:

  • If the session is a Remote Control / dispatch session → keep OAuth-only (current behavior, correct)
  • If the session is an SSH session → use CLI-style credential resolution chain (cloud provider creds → ANTHROPIC_AUTH_TOKENANTHROPIC_API_KEYapiKeyHelper → OAuth fallback)

Concretely, this means the SSH session bootstrap should:

  1. Read CLAUDE_CODE_USE_BEDROCK / CLAUDE_CODE_USE_VERTEX / CLAUDE_CODE_USE_FOUNDRY from the remote environment
  2. Call apiKeyHelper if configured
  3. Read ANTHROPIC_AUTH_TOKEN / ANTHROPIC_API_KEY from the remote environment
  4. Only fall back to OAuth if none of the above are present

This is already the correct behavior for CLI sessions — SSH sessions in the Desktop app should be treated as CLI sessions on a remote machine, not as Remote Control sessions.

Alternative Solutions

_No response_

Priority

Critical - Blocking my work

Feature Category

Configuration and settings

Use Case Example

_No response_

Additional Context

_No response_

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗