fix: Windows Credential Manager path broken (SecureString handling)

[wcruz-br]

Problem

The _load_from_windows_credential_manager() function uses PowerShell's Get-StoredCredential cmdlet, which:

1. Requires the CredentialManager module — not installed by default on Windows.
2. Returns a PSCredential object whose .Password property is a SecureString, not a byte array. The current script attempts [System.Text.Encoding]::UTF8.GetString($_) on it, which fails silently.

As a result, the Windows Credential Manager path always returns None and falls back to ~/.claude/.credentials.json. Users who installed Claude Code exclusively via the VS Code extension (without ever running the CLI) will still get a FileNotFoundError on Windows.

This was confirmed via debug output during local testing:

[DEBUG] platform.system() = 'Windows'
[DEBUG] Windows Credential Manager result: None
[DEBUG] credentials file result: ok

Correct approach

Two viable options:

Option A — ctypes + CredReadW
Call the Windows Credential Manager API directly from Python using ctypes and advapi32.dll. No external dependencies. Requires defining the CREDENTIALW struct and marshaling the CredentialBlob bytes as UTF-8.

Option B — Fixed PowerShell script
Replace Get-StoredCredential with a pure .NET call that doesn't require the CredentialManager module, and convert SecureString correctly:

$cred = [Windows.Security.Credentials.PasswordVault,Windows.Security.Credentials,ContentType=WindowsRuntime]::new()
$cred.FindAllByResource('Claude Code-credentials') | % { $_.RetrievePassword(); $_.Password }

Additional unknowns

• The target/service name Claude Code-credentials was identified on macOS. The equivalent name used by the VS Code extension on Windows may differ and needs verification by a Windows user with a VS Code-only Claude Code installation.

Testing needed

A Windows user who installed Claude Code exclusively via the VS Code extension (no CLI run, no ~/.claude/.credentials.json present) is needed to validate any fix.