Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix [Bug]: `gateway install --force` breaks AWS credential discovery on EC2 instances with instance roles [1 pull requests, 5 comments, 3 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#61847•Fetched 2026-04-08 02:53:38
View on GitHub
Comments
5
Participants
3
Timeline
11
Reactions
0
Author
JiaDe-WuJiaDe-Wu
Participants
JiaDe-WuJiaDe-Wusharkqwysharkqwywirjowirjo
Timeline (top)
commented ×5labeled ×2cross-referenced ×1mentioned ×1

gateway install --force regenerates the systemd service file and drops user-added Environment entries (e.g. AWS_PROFILE=default), breaking AWS SDK credential discovery on EC2 instances using IAM instance roles for Bedrock access.

Error Message

  1. Error log:

Root Cause

gateway install --force regenerates the systemd service file and drops user-added Environment entries (e.g. AWS_PROFILE=default), breaking AWS SDK credential discovery on EC2 instances using IAM instance roles for Bedrock access.

Fix Action

Workaround

Add AWS_PROFILE=default to ~/.openclaw/.env:

AWS_PROFILE=default

This file is not overwritten by gateway install --force and is loaded by the gateway at startup.

PR fix notes

PR #62673: fix: pass cloud provider env vars through to gateway service

Description (problem / solution / changelog)

PR: fix: pass cloud provider env vars through to gateway service

Target: openclaw/openclaw main branch Branch: fix/aws-service-env-passthrough Fixes: https://github.com/openclaw/openclaw/issues/61847

Summary

buildServiceEnvironment curates a whitelist of env vars for the systemd/launchd service, but excludes all cloud provider variables (AWS_PROFILE, AWS_REGION, AZURE_OPENAI_*, GOOGLE_CLOUD_*). This breaks every headless cloud deployment where credentials come from instance metadata (IMDS) or instance profiles — the most common setup on AWS, Azure, and GCP.

Impact

This is a blocking regression for all AWS Bedrock users who upgrade past 2026.3.24.

We maintain sample-OpenClaw-on-AWS-with-Bedrock, an AWS-published CloudFormation template that deploys OpenClaw on EC2 with Amazon Bedrock. After the switch to pi-coding-agent in 2026.4.5, every new deployment and every upgrade fails with:

No API key found for amazon-bedrock.
Use /login or set an API key environment variable.

Real consequences:

  • Issue #64: User reported deploy failure — the first external report
  • Colleague deployments blocked: Internal team members deploying via our CloudFormation template hit this on first boot, cascading into offline agents, React crashes, and broken admin consoles
  • Upgrade path broken: Users on 2026.3.24 (which used "auth": "aws-sdk" in config) cannot upgrade — we had to pin the version and warn users not to select latest
  • Weeks of debugging: We initially assumed it was a config format issue and iterated through plugins.entries.amazon-bedrock.config.auth, models.providers.amazon-bedrock.auth, and plugin enabled: true — none worked because the root cause is the service environment, not the config file

Root Cause

On EC2 with an IAM instance role:

  1. User's shell has AWS_PROFILE=default → AWS SDK discovers credentials via IMDS ✅
  2. openclaw gateway install writes systemd service with curated env → strips AWS_PROFILE ❌
  3. Gateway service starts → pi-coding-agent checks env vars for cloud credentials → finds nothing → "No API key found"
  4. openclaw gateway install --force (upgrades, doctor --fix) overwrites any manual Environment= additions

The ~/.openclaw/.env workaround works (EnvironmentFile is preserved across reinstalls), but users must discover it themselves — there's no error message pointing to the solution.

Solution

Add SERVICE_CLOUD_PROVIDER_ENV_KEYS — same pattern as the existing SERVICE_PROXY_ENV_KEYS — to pass through cloud provider env vars when present in the host environment:

  • AWS: AWS_PROFILE, AWS_REGION, AWS_DEFAULT_REGION, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN, AWS_BEARER_TOKEN_BEDROCK
  • Azure: AZURE_OPENAI_API_KEY, AZURE_OPENAI_BASE_URL, AZURE_OPENAI_RESOURCE_NAME, AZURE_OPENAI_API_VERSION, AZURE_OPENAI_DEPLOYMENT_NAME_MAP
  • Google: GOOGLE_CLOUD_PROJECT, GOOGLE_APPLICATION_CREDENTIALS

The implementation reuses the existing env reader pattern (refactored into shared readServiceKeysFromEnv helper) and adds one spread in buildCommonServiceEnvironment. Zero behavioral change for users who don't set these vars.

Changes

File: src/daemon/service-env.ts (+50, -2)

ChangeLocationDescription
New constantLine ~65SERVICE_CLOUD_PROVIDER_ENV_KEYS — AWS/Azure/Google env var whitelist
RefactorLine ~95Extract readServiceKeysFromEnv shared helper from readServiceProxyEnvironment
Type updateLine ~43Add cloudProviderEnv to SharedServiceEnvironmentFields
Wire-upLine ~368Spread cloudProviderEnv in buildCommonServiceEnvironment

Testing

ScenarioBeforeAfter
EC2 + IAM role + AWS_PROFILE=default in shell❌ "No API key found"✅ Bedrock works
EC2 + ~/.openclaw/.env workaround✅ works✅ still works (EnvironmentFile precedence)
Local dev (no cloud vars set)✅ no change✅ no change
gateway install --force❌ strips AWS vars✅ preserves them

Verified on: OpenClaw 2026.4.5, EC2 t4g.small (Graviton ARM64), Ubuntu 24.04, Amazon Bedrock Nova 2 Lite.

Operation Steps

# Step 1: Clone fork
cd /tmp
git clone https://github.com/JiaDe-Wu/openclaw.git
cd openclaw

# Step 2: Create branch
git checkout -b fix/aws-service-env-passthrough

# Step 3: Replace src/daemon/service-env.ts with the modified version

# Step 4: Commit and push
git add src/daemon/service-env.ts
git commit -m "fix: pass cloud provider env vars through to gateway service (#61847)"
git push origin fix/aws-service-env-passthrough

# Step 5: Create PR
# Open: https://github.com/openclaw/openclaw/compare/main...JiaDe-Wu:openclaw:fix/aws-service-env-passthrough

Changed files

  • src/daemon/service-env.test.ts (modified, +40/-0)
  • src/daemon/service-env.ts (modified, +59/-2)

Code Example

⚠️ Agent failed before reply: No API key found for amazon-bedrock.
Use /login or set an API key environment variable.

---



---

AWS_PROFILE=default
RAW_BUFFERClick to expand / collapse

Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

gateway install --force regenerates the systemd service file and drops user-added Environment entries (e.g. AWS_PROFILE=default), breaking AWS SDK credential discovery on EC2 instances using IAM instance roles for Bedrock access.

Steps to reproduce

  1. Deploy OpenClaw on EC2/ECS/Agent Core/Lambda with IAM instance/services role granting Bedrock access
  2. Configure amazon-bedrock provider with "auth": "aws-sdk" in openclaw.json
  3. Manually add Environment=AWS_PROFILE=default to the systemd service file to make credential chain work
  4. Run openclaw gateway install --force (or upgrade triggers reinstall)
  5. Gateway restarts via systemd
  6. Main agent works, but pi-coding-agent subagent fails

Expected behavior

  1. gateway install --force should preserve user-added Environment= entries in the systemd service file, or provide a documented override mechanism (e.g. systemd drop-in directory or config-level env block)
  2. pi-coding-agent should inherit the parent gateway's amazon-bedrock provider config including "auth": "aws-sdk", not require a separate API key
  3. AWS SDK credential chain (Instance Role → IMDS) should work out of the box in systemd environments on EC2

Actual behavior

  1. gateway install --force regenerates the entire systemd service file, dropping any manually added Environment= entries (e.g. AWS_PROFILE=default)
  2. pi-coding-agent fails with: No API key found for amazon-bedrock
  3. Adding AWS_PROFILE=default to the service file fixes it, but gets overwritten on next gateway install --force
  4. Error log:
⚠️ Agent failed before reply: No API key found for amazon-bedrock.
Use /login or set an API key environment variable.

OpenClaw version

2026.4.5 (3e72c03)

Operating system

Ubuntu 24.04 (arm64) on AWS EC2

Install method

npm global

Model

amazon-bedrock/global.anthropic.claude-opus-4-6-v1

Provider / routing chain

openclaw -> amazon-bedrock (Bedrock Converse Stream API)

Additional provider/model setup details

EC2 Instance Role with Bedrock access policy. Provider config uses "auth": "aws-sdk" in openclaw.json. No API keys — relies on IMDS credential chain.

Logs, screenshots, and evidence

Impact and severity

No response

Additional information

Workaround

Add AWS_PROFILE=default to ~/.openclaw/.env:

AWS_PROFILE=default

This file is not overwritten by gateway install --force and is loaded by the gateway at startup.

Related Issues

  • #17226 — Stale OPENCLAW_GATEWAY_TOKEN in systemd service after upgrade
  • #28236 — --profile flag does not override inherited env vars during gateway install
  • #11805 — Gateway status fails on EC2/headless servers due to missing user-level systemd

extent analysis

TL;DR

To prevent gateway install --force from dropping user-added Environment entries, add the required environment variables to ~/.openclaw/.env, which is not overwritten by the install process.

Guidance

  • Add AWS_PROFILE=default to ~/.openclaw/.env to preserve the environment variable across gateway install --force operations.
  • Verify that the pi-coding-agent subagent can inherit the parent gateway's amazon-bedrock provider config, including the "auth": "aws-sdk" setting, without requiring a separate API key.
  • Check the systemd service file for any other manually added Environment entries that may be dropped during the gateway install --force process and add them to ~/.openclaw/.env as needed.
  • Consider exploring the related issues (#17226, #28236, #11805) for potential connections to the current problem and possible additional workarounds or fixes.

Notes

The provided workaround may not address the underlying issue of gateway install --force regenerating the systemd service file and dropping user-added Environment entries. Further investigation into the OpenClaw version and install method may be necessary to determine a more permanent solution.

Recommendation

Apply the workaround by adding the required environment variables to ~/.openclaw/.env, as this provides a reliable method to preserve the variables across gateway install --force operations, even if it does not address the root cause of the issue.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

  1. gateway install --force should preserve user-added Environment= entries in the systemd service file, or provide a documented override mechanism (e.g. systemd drop-in directory or config-level env block)
  2. pi-coding-agent should inherit the parent gateway's amazon-bedrock provider config including "auth": "aws-sdk", not require a separate API key
  3. AWS SDK credential chain (Instance Role → IMDS) should work out of the box in systemd environments on EC2
#api#inference speed#output truncation#response parsing#environment variable

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING