›_ Claude Code Issues
Claude Code Issues / #36287

[BUG] credential_process fails on second API call in session (2.1.79 regression)

Status Fixed / completed
Reported on v2.1.77
Maintainer reply ✓ Yes — blois
Activity 7 comments · opened Mar 19, 2026 · closed Mar 20, 2026
💡 Likely answer: A maintainer (blois, collaborator) responded on this thread — see the highlighted reply below.

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

The first Bedrock API call in a session succeeds (e.g., simple query with no tool use). All subsequent API calls fail immediately (~6-15ms) with "Could not load credentials from any providers" — even though credential_process continues to run successfully when invoked directly.
Evidence:

  • Debug logs show credential_process script executes and returns valid credentials every time
  • First API call: succeeds, takes ~244ms (credential resolution time)
  • Second API call: fails in 6-15ms (cached failure, no subprocess spawn)
  • The fast failure time indicates credentials are cached as "failed" after the first tool execution

What Should Happen?

When using credential_process for Bedrock authentication, all API calls within a session should resolve credentials successfully. The second and subsequent API calls (e.g., after tool execution) should invoke credential_process the same way the first call does, rather than using a cached failure state. Tool-use queries should work identically to simple queries.

Error Messages/Logs

First API call (succeeds):
2026-03-19T15:30:10.711Z [DEBUG] [API:request] Creating client
2026-03-19T15:30:10.712Z [DEBUG] [API:auth] OAuth token check complete
2026-03-19T15:29:56.044Z [DEBUG] Stream started - received first chunk                                                                    

Second API call after tool execution (fails immediately):
2026-03-19T15:30:10.711Z [DEBUG] [API:request] Creating client
2026-03-19T15:30:10.727Z [ERROR] API error (attempt 1/11): Could not load credentials from any providers
Timing evidence showing cached failure (6ms vs 244ms for fresh credential resolution):
- First call: ~244ms (time to spawn python subprocess and get credentials)
- Second call: 6-15ms (no subprocess, returns cached failure)
Credential process debug logs prove the script works when called:
2026-03-19T15:29:37.716750+00:00 pid=29640 INVOKED
2026-03-19T15:29:40.480753+00:00 pid=29640 SUCCESS expiry=2026-03-19T16:00:02Z

The credential_process executes successfully throughout the session, but the AWS SDK client in claude.exe stops invoking it after the first API call.

Steps to Reproduce

Reproduction: Configure credential_process in AWS config, make a query requiring tool use (e.g., "List files"). First API call succeeds, second fails after tool execution.

Claude Model

Not sure / Multiple models

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Claude Code Extension: 2.1.77 (win32-x64)

Claude Code Version

2.1.79 (Claude Code)

Platform

AWS Bedrock

Operating System

Windows

Terminal/Shell

VS Code integrated terminal

Additional Information

Claude Code can be used from the terminal and the credential_process authentication functions as expected. This is only an issue in the VSCode extension for Claude Code and only in the most recent update that came down on 18-March-26.

View original on GitHub ↗

7 Comments

github-actions[bot] · 5 months ago

Found 3 possible duplicate issues:

  1. https://github.com/anthropics/claude-code/issues/33156
  2. https://github.com/anthropics/claude-code/issues/18396
  3. https://github.com/anthropics/claude-code/issues/23399

This issue will be automatically closed as a duplicate in 3 days.

  • If your issue is a duplicate, please close it and 👍 the existing issue instead
  • To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

RH-Matt · 5 months ago

https://github.com/anthropics/claude-code/issues/33156
https://github.com/anthropics/claude-code/issues/18396
https://github.com/anthropics/claude-code/issues/23399

These are similar, not the same.

RH-Matt · 5 months ago

Rolling back to didn't fix. Unsure if this is your problem now. Closing.

RH-Matt · 5 months ago

Rolling back to v2.1.77 does fix things. It's .78 and .79 that don't allow for authenticating via credential_process. Reopening, I think this bug is valid.

RH-Matt · 5 months ago

From Claude Code

Additional observations and corrections — same machine, same session, 2026-03-20

---

Correction to "first call succeeds" behavior

The original report described the first API call succeeding and the second failing. That behavior is conditional on a warm STS credential cache carried over from a prior working session (v2.1.77). In a cold-start session with no cached STS credentials, all 11 retry attempts fail immediately, starting from attempt 1. The two scenarios reconcile as follows:

  • Warm cache (original report, March 19): A valid STS credential was cached from a prior session within the ~1-hour STS window. The first API call consumed that cache and succeeded. Once tool use caused a new AWS SDK client to be instantiated with a fresh provider chain, credential_process was never invoked — failure in 6–15ms.
  • Cold start (March 20): No cached STS credential. All API calls fail. credential_process is never invoked at any point.

Both scenarios point to the same root cause: credential_process is not being invoked by the AWS SDK in v2.1.78+.

---

Root cause hypothesis: settingsEnv not merged into process.env before AWS SDK initialization

On startup, claude.exe logs the following in both v2.1.77 and v2.1.78:

[DEBUG] CA certs: Config fallback - globalEnv keys: , settingsEnv keys: CLAUDE_CODE_USE_BEDROCK,AWS_REGION,AWS_CONFIG_FILE,AWS_PROFILE,AWS_SHARED_CREDENTIALS_FILE

globalEnv is empty. settingsEnv contains all required AWS vars (AWS_CONFIG_FILE, AWS_PROFILE, etc.), read from ~/.claude/settings.json.

The AWS SDK resolves credentials from process.env — i.e., globalEnv. If settingsEnv is not merged into the actual process environment before the AWS credential provider chain is initialized, the SDK never sees AWS_CONFIG_FILE or AWS_PROFILE, skips the credential_process provider entirely, and exits with _"Could not load credentials from any providers."_

The evidence strongly suggests v2.1.78 changed the timing or method of this merge. In v2.1.77, the merge happens early enough that the AWS credential provider chain sees the vars. In v2.1.78+, it does not — or is not happening at all.

---

Before/after comparison from a single session on a single machine

One VSCode window, same settings.json, same credential state, same machine — v2.1.78 loaded first, then reloaded as v2.1.77.

v2.1.78 — all 11 retries fail:

2026-03-20T14:58:53.012Z [DEBUG] attribution header x-anthropic-billing-header: cc_version=2.1.78.a43; cc_entrypoint=claude-vscode
2026-03-20T14:58:53.017Z [DEBUG] [API:request] Creating client, ANTHROPIC_CUSTOM_HEADERS present: false, has Authorization header: false
2026-03-20T14:58:53.017Z [DEBUG] [API:auth] OAuth token check starting
2026-03-20T14:58:53.018Z [DEBUG] [API:auth] OAuth token check complete
2026-03-20T14:58:53.196Z [ERROR] API error (attempt 1/11): Could not load credentials from any providers

... attempts 2–10 omitted, identical pattern, exponential backoff ...

2026-03-20T15:01:45.258Z [DEBUG] [API:request] Creating client
2026-03-20T15:01:45.285Z [DEBUG] [API:auth] OAuth token check complete
2026-03-20T15:01:45.300Z [ERROR] API error (attempt 11/11): Could not load credentials from any providers
2026-03-20T15:01:45.302Z [ERROR] Error in API request: Could not load credentials from any providers

v2.1.77 — loaded immediately after, first call succeeds, session fully functional:

2026-03-20T15:05:13.108Z [DEBUG] [clientData] skipped: not OAuth subscriber or missing profile scope
2026-03-20T15:05:28.081Z [DEBUG] attribution header x-anthropic-billing-header: cc_version=2.1.77.cb0; cc_entrypoint=claude-vscode
2026-03-20T15:05:28.082Z [DEBUG] [API:request] Creating client, ANTHROPIC_CUSTOM_HEADERS present: false, has Authorization header: false
2026-03-20T15:05:28.082Z [DEBUG] [API:auth] OAuth token check starting
→ API calls succeed throughout session

The OAuth token check pattern is identical in both versions and completes without error in both. The divergence is purely in whether the AWS SDK can locate credentials after that check.

---

Version correction

The original report lists the breaking version as 2.1.79. The logs above confirm the break is present in 2.1.78 (cc_version=2.1.78.a43). Both v2.1.78 and v2.1.79 are affected. Last known-good version: 2.1.77 (cc_version=2.1.77.cb0).

---

Why terminal is unaffected

When claude is run from a terminal, the shell process already has AWS_CONFIG_FILE and AWS_PROFILE in its native environment. There is no settingsEnv/globalEnv split — the vars are in process.env unconditionally. The credential_process provider is found, invoked, and returns credentials normally.

The VSCode extension spawns claude.exe as a child process and injects env vars from settings.json as settingsEnv. The regression is in how that injection is applied to the subprocess's actual process environment before AWS SDK initialization.

---

Suggested diagnostic for the Anthropic team

In claude.exe v2.1.78, immediately before the first credential_process invocation attempt, log process.env.AWS_CONFIG_FILE and process.env.AWS_PROFILE. If those are undefined while the same values exist in settingsEnv, the merge-timing regression is confirmed.

blois collaborator · 5 months ago

A fix should be in the next release.

github-actions[bot] · 5 months ago

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.

Related Claude Code issues

Matched on shared title terms, labels, topic and reported release — ranked so issues with real discussion come first.

Browse by topic

Same class of failure, ranked by community engagement — this issue is one of many, so it may not appear in the visible list: Authentication & login failures

Browse all Claude Code issue topics →