claude-cli backend on Windows: selected auth profile token is never used, so Claude Code always runs on its own saved login and profile failover has no effect

Summary

On Windows, the claude-cli runtime hands the selected Anthropic auth-profile token to Claude Code with CLAUDE_CODE_OAUTH_TOKEN_FILE_DESCRIPTOR=3 and a stdio[3] pipe ("overlapped" on win32 in prepareSecretInputStdio). Claude Code doesn't appear to pick up the token. It falls back to its own claude auth login credentials. As a result, every run uses the CLI's saved account, whichever profile OpenClaw selected. Switching to the next auth.order profile restarts the CLI but still sends requests from the exhausted account.

OpenClaw then marks the healthy profile as rate-limited, because it attributes the failure to the profile it thinks it used.

Environment

• OpenClaw 2026.9.6, Claude Code 2.1.280, Windows 11 x64, native (no WSL), gateway run from node dist/index.js gateway
• All anthropic/* models use agentRuntime.id: "claude-cli"
• Two setup-token profiles (sk-ant-oat01-…, different Claude subscriptions): auth.order.anthropic = [anthropic:layne, anthropic:jill]
• Claude Code on the host is logged in (claude auth login) to the anthropic:layne account

Evidence

1. I called /v1/messages directly with each stored token:
   • anthropic:layne → 429, anthropic-ratelimit-unified-7d-status: rejected (weekly limit, resets Oct 3 22:00 UTC)
   • anthropic:jill → 200, 7d-utilization: 0.1, 5h-utilization: 0.01. It's a different anthropic-organization-id.
2. The gateway did switch the ltsa agent to jill. It restarted the CLI with the new profile and still got the layne account's weekly-limit error:

[agent/cli-backend] cli session reset: provider=claude-cli reason=auth-profile
[agent/cli-backend] cli session history refused across auth boundary: reason=auth-unknown
[agent/cli-backend] cli exec: provider=claude-cli model=claude-fable-5-1 ... reuse=invalidated:auth-profile
[agent/cli-backend] cli live session start: provider=claude-cli model=claude-fable-5-1 activeSessions=2
[agent/cli-backend] cli terminal failure: ... durationMs=8261 error=You've hit your weekly limit · resets Oct 3, 10pm (UTC)
[agent/embedded] auth profile failure state updated: profile=sha256:b3f4ccf67e19 provider=anthropic reason=rate_limit window=cooldown reused=false
[model-fallback/decision] decision=candidate_failed requested=anthropic/claude-fable-5-1 reason=rate_limit next=none

sha256:b3f4ccf67e19 = sha256("anthropic:jill"). The reset time in that error matches the layne account exactly. The jill account wasn't limited.

1. Runs on the layne profile (sha256:9b9d3b00eada) failed with the same message and reset time.
2. After I switched Claude Code's own login to the jill account (claude auth logout / claude auth login), all agents worked again. No OpenClaw config changed.

Expected

The token from the selected profile is what Claude Code uses on Windows. If the fd handoff isn't supported there, OpenClaw should either use a Windows-safe transport or refuse to start the run, rather than silently falling back to the CLI's ambient login.

Secondary observations

• An Anthropic weekly-limit error is classified as rate_limit with a 30–60 s cooldown (ltsa's usageStats showed cooldownUntil = failure + 60 s). The reset time is in the error text, so the cooldown could run until the reset instead of retrying the exhausted account every minute. Related to #158144.
• The main agent's auth_profile_store has profiles: {} (only order is set in auth_profile_state), so it always runs on the ambient login.

Related:

• #158144 covers a session staying pinned to a limited profile. This one covers the switch itself having no effect on Windows.
• #141196 was the same fd-3 handoff being ignored on Linux (Claude Code 2.1.251), closed 2026-09-07. It still happens on Windows with Claude Code 2.1.280.