[BUG] [Desktop 3P / Bedrock] WSL-folder Code sessions fail with "Bedrock credentials are managed by the desktop app, but none are available" — remote spawn path does not deliver credentials for any credential kind

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?

In Claude Desktop's third-party (3P) deployment mode with Amazon Bedrock inference, Code-tab sessions started in a WSL folder fail on every turn with a Bedrock credential error. The same app instance, with the same configuration, works everywhere else:

| Surface | Result |
|---|---|
| Cowork sessions | ✅ works |
| Code tab, Windows folder | ✅ works (after switching credential kind from interactive to a named AWS profile — under interactive, Windows Code sessions also failed with the same error, even in the main session after a full restart and AWS re-sign-in) |
| Code tab, WSL folder | ❌ fails, under both interactive and named-profile credential kinds |
| Standalone claude inside the WSL terminal (own settings: CLAUDE_CODE_USE_BEDROCK=1 + AWS profile) | ✅ works |

main.log shows WSL sessions spawn via the remote/SSH path using the app-deployed engine (~/.claude/remote/ccd-cli/2.1.246). The session initializes fully (MCP connects, first assistant frame arrives), then the first API cycle fails immediately — so this is not a spawn or permissions failure. The remotely spawned CLI resolves its credential kind as "desktop-managed" and no credentials are ever delivered.

Suspected cause: the remote spawn path (used for wsl: targets) injects the desktop-managed credential kind unconditionally and has no credential delivery mechanism to the remote session — for any Bedrock credential kind, since even in named-profile mode the desktop app brokers credentials (it runs aws sso login on the user's behalf). Remote-spawned sessions appear to land in the same unsupported bucket as background agents/teammates.

Already ruled out:

• Full app quit/relaunch; staged update applied (1.37937.1 → 1.37937.3)
• AWS re-sign-in (interactive kind) — no change
• Named profile present and verified via aws sts get-caller-identity in both Windows and WSL
• WSL CLI up to date (2.1.247); app-deployed engine is 2.1.246
• App-deployed binary ownership/permissions correct (rwxr-xr-x, owned by WSL user) and it demonstrably executes
• No MDM/registry policy on the device (HKCU/HKLM\SOFTWARE\Policies\Claude both empty); config authored via the in-app Configure Third-Party Inference window
• Corporate TLS interception handled for AWS CLI in WSL (SSO login succeeds)

Minor note: Windows and WSL usernames differ on this machine (normal WSL setup). Binary deployment resolved the correct WSL home, so this is likely not the cause, but noting it in case credential delivery derives a WSL path from the Windows identity.

What Should Happen?

WSL-folder Code sessions should honor the configured Bedrock credential kind the same way Windows-folder sessions do — either resolving the named profile against WSL's ~/.aws, or receiving brokered credentials from the desktop app.

Error Messages/Logs

Error shown on every turn in a WSL-folder Code session:


API Error: Bedrock credentials are managed by the desktop app, but none are available.
Background agents and teammates are not supported for this credential kind.
Run this from the main session, or switch the desktop app to a profile-based or
API-key credential. If this is the main session, restart the desktop app.


Relevant `main.log` excerpt (IDs redacted):


[info] LocalSessions.checkRemoteTargetTrust: target=wsl:Ubuntu, cwd=~
[info] [SSH] Using remote spawn function for session <id> on wsl:Ubuntu (cli: /home/<user>/.claude/remote/ccd-cli/2.1.246)
[info] [CCD start-timing] <id> ... init=3867ms first_assistant=56ms ... cache_hit=true
[warn] [CCD CycleHealth] <id> api_error (success): API Error: Bedrock credentials are managed by the desktop app, but none are available. ...
[info] [CCD CycleHealth] unhealthy cycle for <id> (4s, hadFirstResponse=true, reason=api_error)

Steps to Reproduce

1. Install Claude Desktop on Windows in third-party (3P) deployment mode.
2. Configure Bedrock inference via the in-app window (Developer Mode → Configure Third-Party Inference): provider bedrock, region us-east-1, credential kind = named AWS profile (also reproduces with interactive / in-app IAM Identity Center sign-in).
3. Define the named profile (IAM Identity Center sso-session stanza) in both Windows %USERPROFILE%\.aws\config and WSL ~/.aws/config. Verify in both environments:

``
aws sso login --profile <profile>
aws sts get-caller-identity --profile <profile> # returns expected assumed-role ARN
``

1. Apply the config locally and relaunch the app.
2. Open the Code tab and start a session in a Windows folder → works.
3. Open the Code tab and start a session in a WSL folder (target wsl:Ubuntu, any path).
4. Send any message → fails with the credential error above.

Claude Model

Other

Is this a regression?

I don't know

Last Working Version

N/A / unknown

Claude Code Version

Embedded engine deployed by the desktop app into WSL: 2.1.246 (~/.claude/remote/ccd-cli/2.1.246). Standalone WSL install (not used by the app): 2.1.247. Desktop app: 1.37937.3.

Platform

AWS Bedrock

Operating System

Windows

Terminal/Shell

Other

Additional Information

• No MDM/managed policy on the device — nothing under HKCU\SOFTWARE\Policies\Claude or HKLM\SOFTWARE\Policies\Claude; configuration is user-authored via the in-app configuration window.
• The in-app config ($schemaVersion: 2) previously used "credential": { "kind": "interactive" } with IAM Identity Center SSO; switching to the named-profile kind fixed Windows-folder Code sessions but not WSL.
• Corporate environment with TLS interception; corporate root CA is trusted in WSL and AWS CLI SSO flows succeed there.
• Windows username differs from WSL username (standard WSL configuration).
• Happy to provide a full diagnostic report (Help → Troubleshooting → Generate Diagnostic Report) on request.