Feature Request: SSH-agent-style credential forwarding for remote Claude Code sessions
Status Closed — not planned
Maintainer reply None cached
Activity 7 comments · opened Apr 16, 2026 · closed May 25, 2026
Problem
When running Claude Code on a remote server via SSH, credentials (API key or OAuth token) must be stored on the remote filesystem. On shared servers where other users have root access, this is a security concern — root can read tokens from ~/.claude/ or /proc/*/environ.
There is no equivalent to SSH's ssh-agent forwarding, where the secret never leaves the local machine.
Proposed Solution
A local claude-auth-agent daemon (analogous to ssh-agent) that:
- Runs on the local machine, holds the API key / OAuth token in memory
- Exposes a Unix socket (e.g.
CLAUDE_AUTH_SOCK) - The socket is forwarded via
ssh -Rto the remote server - Remote Claude Code talks to the forwarded socket for API authentication
# Local
eval $(claude-auth-agent)
ssh -R /tmp/claude-auth.sock:$CLAUDE_AUTH_SOCK -p 42222 user@server
# Remote — key never touches the server
export CLAUDE_AUTH_SOCK=/tmp/claude-auth.sock
claudeWhy
- API keys / OAuth tokens never leave the local machine
- Revocation is instant (kill the local agent)
- Familiar pattern — every developer already knows
ssh-agentforwarding - Shared/multi-tenant servers become safe to use
Related Issues
- #42965 — OAuth broken for remote/headless setups
- #7100 — Headless/remote authentication (auto-closed)
- #44089 — Keychain inaccessible from SSH sessions
- #29717 — SSH_AUTH_SOCK forwarding for 1Password agent
7 Comments
SSH-agent-style credential forwarding is the right security model for remote Claude Code sessions — the principle that credentials should never leave the machine that owns them is well-established in the SSH ecosystem, and the same principle applies to Claude API keys and OAuth tokens.
From an agent identity perspective, the credential forwarding model also cleanly separates two concepts: the agent's operational context (which runs on the remote server, has access to the remote filesystem, runs remote commands) and the agent's authentication identity (which should remain under the user's local control). The agent executes remotely but proves its identity locally.
The
CLAUDE_AUTH_SOCKUnix socket approach is the correct implementation pattern. A few additional considerations:1. Socket authentication. The forwarded socket should require a connection token or use filesystem permissions (mode 600, owned by the session user) to prevent other processes on the remote server from using the forwarded credential.
2. Credential scope. The local agent should be able to issue scoped tokens — a token that authorizes remote Claude Code to make API calls but does not grant access to the user's account management, billing, or other capabilities. The remote agent gets only what it needs.
3. Audit logging. Every API call made through the forwarded socket should be loggable on the local machine, not just the remote. This gives the user visibility into what the remote agent did with their credentials even if the remote logs are inaccessible or tampered.
This is directly composable with SATP behavioral attestations — the remote agent's actions, authenticated through the forwarded socket, can be attributed to the specific user identity that authorized the forwarding, creating a complete behavioral audit trail.
Arent you overcomplicating it?
Host server
SendEnv OPENROUTER_API_KEY GEMINI_API_KEY GOOGLE_GENERATIVE_AI_API_KEY
...
AcceptEnv GEMINI_API_KEY OPENROUTER_API_KEY GOOGLE_GENERATIVE_AI_API_KEY
Hi and thanks for the suggestions.
Thats at least a better approach than writing the credentials file to the remote server. However it still is vulnerable to whoever has root access on the server. (Though i understand that using claude code on a server where you don't trust the other users is questionable).
Sadly the token generated when using a subscription plan is valid for a full year (can be manually revoked).
So i my opinion a doable solution would be for the remote claude code cli to send its request back to the host (via socket), then the local claude code cli adds the authentification token and sends the message to Anthropics Servers - acting as a proxy that just adds the authentification for the remote host where cc cli is currently working.
Another idea would be signing each request via the proxy, or for the local claude code to create short lived tokens for use by the remote claude cli.
Closing for now — inactive for too long. Please open a new issue if this is still relevant.
why is this closed? this is a real security risk
Re open please we need this!
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.