[FEATURE] Desktop app SSH sessions should use CLI-style credential resolution, not OAuth-only Remote Control auth (3P providers & LLM gateways)
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_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_FOUNDRYfrom the remote environment - Call
apiKeyHelperif configured - Read
ANTHROPIC_AUTH_TOKEN/ANTHROPIC_API_KEYfrom 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.
Alternative Solutions
_No response_
Priority
Critical - Blocking my work
Feature Category
Configuration and settings
Use Case Example
_No response_
Additional Context
_No response_
This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗