[FEATURE] Support AWS Bedrock + AWS SSO in `claude remote-control`

Status Open
Maintainer reply None cached
Activity 14 comments · opened Feb 26, 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

Current Behavior

When a user running Claude Code via AWS Bedrock attempts to start a Remote Control session, they are blocked at the authentication layer. The Remote Control handshake requires an Anthropic account session token — which Bedrock users do not have, and cannot obtain without signing up for a separate consumer plan.

Blocked flow
aws sso login → CLAUDE_CODE_USE_BEDROCK=1 → claude remote-control → ❌ Requires Anthropic login

Who Is Affected

Enterprise and team users who access Claude Code through AWS Bedrock under corporate AWS accounts
Developers and data engineers using AWS SSO / IAM Identity Center for unified credential management
Organizations with security policies that prohibit direct Anthropic account creation for individual developers
AWS-native teams who have already invested in Bedrock-based Claude Code setup and want feature parity

Business Impact

Remote Control is a high-value feature — it enables developers to monitor and steer long-running agentic tasks from mobile devices without being physically present at their workstation. Blocking Bedrock users from this feature creates a significant capability gap and undermines the value proposition of the AWS Bedrock integration.

Proposed Solution

Decoupled Auth Backend

Extend the Remote Control session registration to accept AWS Bedrock credentials in addition to Anthropic account tokens. When CLAUDE_CODE_USE_BEDROCK=1 is set, the Remote Control handshake should authenticate against AWS STS rather than the Anthropic account system.

# Desired flow
export CLAUDE_CODE_USE_BEDROCK=1
export AWS_PROFILE=my-sso-profile
export AWS_REGION=us-east-1

aws sso login --profile my-sso-profile
claude remote-control   # ✅ Should work with Bedrock credentials

SSO Token Refresh in Remote Sessions

Since AWS SSO credentials have a finite TTL, the Remote Control session should honour the existing awsAuthRefresh mechanism — automatically triggering re-authentication when credentials expire, without dropping the active remote session.

// ~/.claude/settings.json
{
  "env": {
    "CLAUDE_CODE_USE_BEDROCK": "1",
    "AWS_PROFILE": "my-sso-profile",
    "AWS_REGION": "us-east-1"
  },
  "awsAuthRefresh": "aws sso login --profile my-sso-profile --no-browser"
}

Suggested Implementation Approach

  1. Abstract the Remote Control auth layer behind an interface that supports multiple identity providers (Anthropic account, AWS STS, and potentially others in future).
  2. When CLAUDE_CODE_USE_BEDROCK=1 is detected, use the AWS SDK credential chain to obtain a caller 3. identity via sts:GetCallerIdentity and use this as the session identity for Remote Control registration.
  3. Issue a short-lived Remote Control session token scoped to the AWS ARN, refreshable via awsAuthRefresh.

Ensure the Remote Control relay server can validate both Anthropic-issued and AWS STS-backed session tokens.

Alternative Solutions

| Alternative | Why It Falls Short |
|---|---|
| Use tmux over SSH | Requires always-on SSH connection; no mobile-friendly UI; not equivalent to native Remote Control UX |
| Dual auth (Anthropic + Bedrock) | Forces enterprise users to create personal Anthropic accounts, which may violate corporate security policies |
| claude --print for automation | Headless only; no interactive remote monitoring; not a substitute for Remote Control |
| Wait for Team/Enterprise RC support | Does not address the Bedrock auth gap; Team/Enterprise plans may still require Anthropic account login |

Priority

High - Significant impact on productivity

Feature Category

CLI commands and flags

Use Case Example

claude remote-control currently requires authentication via an Anthropic account (/login → claude.ai). This prevents users who access Claude Code through AWS Bedrock from using the feature at all — even though they are legitimate, paying Claude Code users accessing Claude through an officially supported channel.

This request asks the Anthropic engineering team to extend claude remote-control to support AWS Bedrock as an authentication backend, including credential flows via AWS SSO (IAM Identity Center).

Additional Context

_No response_

View original on GitHub ↗

14 Comments

josheche · 7 months ago

Need this yesterday.

Aflous · 7 months ago

Needed this last year 🥲

jayson-gallardo · 7 months ago

I'm having to try and build a bridge to Microsoft Teams when we could just have this!

frankpinto · 5 months ago

SIGNIFICANT IMPACT ON PRODUCTIVITY. Yes, pls let's get this

grillir · 5 months ago

Critical feature that would resolve current significant impact to my productivity.

lillycmt · 5 months ago

Need this!!!

dyst5422 · 5 months ago

I don't see this happening. The remote control needs some networking integration that costs money and Claude code doesn't see that money when you use bedrock.

monumental-smm · 5 months ago

I have a Teams / Premium subscription, but mainly work through Bedrock for my main billing. I see what @dyst5422 is saying, but, customers should be able to dual-wield logins to max the capabilities they're paying for.

dyst5422 · 5 months ago

I could see that - the subscription requires for remote even if the model runs via bedrock.

christian-atg · 4 months ago

Also consider making it possible to use an existing claude code account (personal subscription) to remote-control the enterprise session that uses bedrock

huzheyuan-tri · 3 months ago

Please add this feature, very important for productivity!

alejacre · 1 month ago

Same blocker in Claude Desktop 3P mode (Amazon Bedrock) SSH remote sessions, not only remote-control.

Per the docs, remote sessions on Bedrock accept only a bearer token or a credential helper that returns a bearer token, and refuse named-profile / in-app AWS SSO. Many enterprise Bedrock roles are SigV4-only and are not granted bedrock:CallWithBearerToken (403 when we tried a token from aws-bedrock-token-generator), so there is no supported path at all for those deployments. Meanwhile the remote host already has a working Claude Code + Bedrock setup that the remote engine ignores by design.

Either of these would unblock it:

  1. Let the credential helper return SigV4 credentials (AccessKeyId/SecretAccessKey/SessionToken/Expiration, same shape as awsCredentialExport), refreshed by Desktop and forwarded to the remote engine as AWS_* env vars.
  2. An opt-in to let the remote engine use the host's own CLAUDE_CODE_USE_BEDROCK / awsCredentialExport configuration.

Related: #90202, #77247, #83561. Desktop 1.44121.4.

ashwinkrishnan-lab · 27 days ago

Has Claude given up on Desktop? I end up using alternate tools because this feature isn't present. Cursor and Codex offer this natively and set up is trivial.

fxerkan · 9 days ago

I developed a small sidecar tool that I think can solve this problem; it should at least help until the Claude Code team adds this feature natively. I hope you find it useful.

https://github.com/fxerkan/ccbridger

https://medium.com/@fxerkan/remote-control-for-api-based-claude-code-approve-bedrock-vertex-foundry-sessions-from-your-bb580c914f8e