[FEATURE] Separate AWS profile for Bedrock API calls vs. shell command environment

Resolved 💬 4 comments Opened Feb 12, 2026 by kejadlen Closed Mar 14, 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

Claude Code on AWS Bedrock requires AWS_PROFILE set to the Bedrock-authorized profile (e.g. bedrock-users). That environment variable propagates into every shell command Claude executes — docker, bin/server, aws calls, and anything else that reads AWS credentials.

This means commands that need a different AWS profile (the engineer's team profile, default, etc.) silently authenticate with the wrong identity. The consequences range from confusing permission errors to false-positive security alerts when the Bedrock profile accesses resources it shouldn't.

The only workaround today is instructing Claude to prefix every shell command with AWS_PROFILE=default, which is fragile and easy to forget.

Proposed Solution

Introduce a configuration option (e.g. bedrock_aws_profile) that Claude Code uses exclusively for its own Bedrock API calls. Shell commands invoked by Claude should inherit the user's ambient environment — or a separately configurable profile — rather than the Bedrock profile.

Something like:

{
  "bedrock_aws_profile": "bedrock-users",
}

Or simply: use the Bedrock profile only for model inference requests and do not export it into the shell environment.

Alternative Solutions

  • Telling Claude via CLAUDE.md to prepend AWS_PROFILE=default to shell commands — unreliable, since Claude doesn't always follow this.
  • A wrapper/launcher script that unsets AWS_PROFILE before invoking subprocesses — possible but shouldn't be necessary.
  • Adding Bedrock permissions to the engineer's default profile — rejected for least-privilege reasons.

Priority

High - Significant impact on productivity

Feature Category

Configuration and settings

Use Case Example

  1. Engineer configures AWS_PROFILE=bedrock-users so Claude Code can reach Bedrock.
  2. Engineer asks Claude to run bin/server to analyze application logs.
  3. bin/server inherits bedrock-users, which lacks permissions for ECR, application databases, etc.
  4. Commands fail or — worse — succeed against the wrong account/role, triggering security alerts.
  5. With this feature, Bedrock calls would use bedrock-users while bin/server runs under the engineer's normal profile.

Additional Context

Previous issues requesting this: #148 (closed/locked), #20384 (closed as duplicate of #148). The underlying need remains unaddressed. This is a real friction point for organizations that enforce separate AWS profiles for Bedrock access vs. day-to-day development.

View original on GitHub ↗

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