[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](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) 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

```shell
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 on wsl:Ubuntu (cli: /home//.claude/remote/ccd-cli/2.1.246)
[info] [CCD start-timing] ... init=3867ms first_assistant=56ms ... cache_hit=true
[warn] [CCD CycleHealth] api_error (success): API Error: Bedrock credentials are managed by the desktop app, but none are available. ...
[info] [CCD CycleHealth] unhealthy cycle for (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
aws sts get-caller-identity --profile # returns expected assumed-role ARN
```
4. Apply the config locally and relaunch the app.
5. Open the Code tab and start a session in a Windows folder → works.
6. Open the Code tab and start a session in a **WSL folder** (target `wsl:Ubuntu`, any path).
7. 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.

Start with the LocalSessions.checkRemoteTargetTrust and remote spawn entries in main.log, focusing on WSL targets and the app-deployed CLI at ~/.claude/remote/ccd-cli/2.1.246. Compare credential handling for Windows-folder and WSL-folder Code sessions under named-profile and interactive kinds. Done means a WSL session honors the configured Bedrock credential kind and completes an API cycle without the missing-credentials error.

Escrito por el modelo de indexación a partir del texto del issue.