← Notas

Sistemas 13 AGO

Cuando Contraseñas de iCloud no funciona en Chrome en Windows: diagnóstico y solución

Durante años tuve un problema muy concreto en uno de mis equipos con Windows 11.

Durante años tuve un problema muy concreto en uno de mis equipos con Windows 11.

Utilizaba iCloud para Windows y la extensión Contraseñas de iCloud en Google Chrome, pero la integración no funcionaba como debía.

En otros equipos, al pulsar la extensión, iCloud genera un código de seis dígitos. Después de validarlo, la extensión puede mostrar las credenciales guardadas para el dominio y ayudar a rellenar el inicio de sesión.

En este portátil ocurría algo diferente.

Al pulsar la extensión, en lugar de aparecer ese código, Chrome simplemente abría iCloud para Windows. La aplicación de Contraseñas de iCloud funcionaba correctamente y permitía consultar las credenciales manualmente, pero para utilizarlas en una web había que abrir el gestor, buscar la cuenta y copiar usuario y contraseña.

Funcional, sí.

Práctico, no demasiado.

El síntoma real

El comportamiento anómalo era este:

la extensión estaba instalada en Chrome;
iCloud para Windows estaba operativo;
la base de contraseñas podía abrirse manualmente;
pero al pulsar la extensión no aparecía el código de seis dígitos;
en su lugar, Chrome enviaba siempre a abrir iCloud para Windows.

Ese detalle era importante, porque indicaba que el problema no estaba en las credenciales en sí, sino en la comunicación entre Chrome e iCloud.

Cómo funciona realmente

La extensión de Contraseñas de iCloud no accede directamente al llavero de Apple.

La cadena de comunicación es aproximadamente esta:

Extensión de Chrome
        ↓
Chrome Native Messaging
        ↓
com.apple.passwordmanager
        ↓
iCloudPasswordsExtensionHelper.exe
        ↓
Contraseñas de iCloud

Chrome utiliza su mecanismo Native Messaging para comunicarse con aplicaciones instaladas en Windows. Para ello depende de una entrada de Registro que apunta a un manifiesto JSON. Ese manifiesto le indica a Chrome qué ejecutable debe arrancar.

En este caso, el componente implicado era:

com.apple.passwordmanager

Primeras comprobaciones

Antes de tocar nada, las comprobaciones iniciales fueron estas:

Get-ItemProperty 'HKCU:\Software\Google\Chrome\NativeMessagingHosts\com.apple.passwordmanager' -ErrorAction SilentlyContinue

Get-ItemProperty 'HKLM:\Software\Google\Chrome\NativeMessagingHosts\com.apple.passwordmanager' -ErrorAction SilentlyContinue

Get-ItemProperty 'HKLM:\Software\WOW6432Node\Google\Chrome\NativeMessagingHosts\com.apple.passwordmanager' -ErrorAction SilentlyContinue

Y además:

Test-Path "$env:LOCALAPPDATA\Microsoft\WindowsApps\iCloudPasswordsExtensionHelper.exe"

Get-Item "$env:LOCALAPPDATA\Microsoft\WindowsApps\iCloudPasswordsExtensionHelper.exe" -ErrorAction SilentlyContinue | Format-List *

Con estas comprobaciones vimos dos cosas importantes:

Solo existía la entrada de Apple en HKLM.
Windows sí tenía disponible el alias moderno del helper en:

%LOCALAPPDATA%\Microsoft\WindowsApps\iCloudPasswordsExtensionHelper.exe

El manifiesto original

Después comprobamos el manifiesto que estaba utilizando la instalación de iCloud:

Get-Content 'C:\Program Files\WindowsApps\AppleInc.iCloud_13.4.101.0_x86__nzyj5cx40ttqa\iCloud\ChromePwdMgrHostApp\_manifest.json'

Su contenido era esencialmente este:

{
  "name": "com.apple.passwordmanager",
  "description": "Apple iCloud Chrome/Edge Password Manager Host App",
  "path": "iCloudPasswordsExtensionHelper.exe",
  "type": "stdio",
  "allowed_origins": [
    "chrome-extension://pejdijmoenmkgeppbflobdenhhabjlaj/",
    "chrome-extension://mfbcdcnpokpoajjciilocoachedjkima/"
  ]
}

Aparentemente el manifiesto estaba bien formado. También existía la instalación de iCloud a la que apuntaba. Es decir: no era el típico caso de ruta inexistente o instalación completamente rota.

Hallazgo clave

Aquí empezó lo interesante.

Aunque la configuración oficial existía y el JSON era razonable, Chrome no estaba consiguiendo comunicarse correctamente con el helper de Apple. El síntoma encajaba con otros casos recientes en los que el Native Messaging Host encontraba el manifiesto, pero el helper fallaba al arrancar o al comunicarse desde el paquete protegido de WindowsApps.

Por eso reinstalar Chrome, iCloud o la extensión no cambiaba nada.

Se estaba reconstruyendo el software, pero la integración seguía quedando igual.

La idea del workaround

En lugar de depender de la integración oficial publicada en HKLM, la solución fue crear una integración propia en HKCU para el usuario actual.

La lógica era sencilla:

no tocar la entrada oficial de Apple;
no sustituir el ejecutable de Apple;
no instalar software de terceros;
simplemente decirle a Chrome que, para este usuario, utilice un manifiesto alternativo;
y que ese manifiesto arranque el helper usando el App Execution Alias estable de Windows.

Es decir, pasar de algo así:

Chrome
  ↓
HKLM
  ↓
Program Files\WindowsApps\versión concreta

A esto:

Chrome
  ↓
HKCU
  ↓
Windows App Execution Alias
  ↓
iCloudPasswordsExtensionHelper.exe

Crear el workaround

El bloque exacto de PowerShell que utilizamos fue este:

$FixDir = "$env:LOCALAPPDATA\iCloudChromeFix"
New-Item -ItemType Directory -Path $FixDir -Force | Out-Null

$Manifest = @"
{
  "name": "com.apple.passwordmanager",
  "description": "Apple iCloud Chrome Password Manager Host via WindowsApps alias",
  "path": "$($env:LOCALAPPDATA.Replace('\\','\\\\'))\\Microsoft\\WindowsApps\\iCloudPasswordsExtensionHelper.exe",
  "type": "stdio",
  "allowed_origins": [
    "chrome-extension://pejdijmoenmkgeppbflobdenhhabjlaj/",
    "chrome-extension://mfbcdcnpokpoajjciilocoachedjkima/"
  ]
}
"@

$Manifest | Set-Content "$FixDir\ChromePwdMgrHostApp_manifest.json" -Encoding ASCII

New-Item -Path 'HKCU:\Software\Google\Chrome\NativeMessagingHosts\com.apple.passwordmanager' -Force | Out-Null

Set-ItemProperty `
  -Path 'HKCU:\Software\Google\Chrome\NativeMessagingHosts\com.apple.passwordmanager' `
  -Name '(default)' `
  -Value "$FixDir\ChromePwdMgrHostApp_manifest.json"

Comprobación del registro y del manifiesto

Después verificamos que todo hubiese quedado correctamente:

Get-ItemProperty 'HKCU:\Software\Google\Chrome\NativeMessagingHosts\com.apple.passwordmanager'

Y también revisamos el JSON generado:

Get-Content "$env:LOCALAPPDATA\iCloudChromeFix\ChromePwdMgrHostApp_manifest.json"

En este punto, Chrome ya tenía una definición de com.apple.passwordmanager específica para el usuario actual, y esa definición apuntaba al alias moderno de Windows en lugar de a la ruta versionada del paquete.

Cerrar Chrome de verdad

No bastaba con cerrar la ventana del navegador.

Chrome deja procesos en segundo plano, así que era necesario matarlo completamente:

taskkill /F /IM chrome.exe

Después de eso, se volvió a abrir Chrome y se repitió la prueba.

Resultado

Aquí llegó la confirmación importante.

Al pulsar de nuevo la extensión, apareció por fin el código de verificación de seis dígitos.

Ese detalle confirmaba que el puente entre Chrome e iCloud se había reparado.

No era una impresión subjetiva. Era una evidencia clara de que el componente Native Messaging ya estaba funcionando.

Lo que aún puede fallar

Una vez resuelta la comunicación, apareció una segunda cuestión: en algunas webs no se sugería automáticamente la credencial.

Eso ya era otro problema distinto.

Cuando el código de seis dígitos ya aparece y la extensión funciona en algunas webs, la integración Chrome ↔ iCloud está reparada. Lo que puede quedar pendiente depende de cómo esté construido cada formulario.

Por ejemplo:

formularios dinámicos;
inicios de sesión en dos pasos;
iframe;
subdominios distintos;
atributos HTML poco estándar;
dominios guardados como dominio.com pero acceso real en login.dominio.com;
páginas que gestionan o bloquean el autocompletado de forma especial.

También puede influir el permiso de la extensión dentro de Chrome.

En este caso se revisó:

chrome://extensions/ → Contraseñas de iCloud → Detalles → Acceso al sitio → En todos los sitios

Y se comprobó que, efectivamente, en unas webs sí sugería la credencial y en otras no.

Eso ya entraba dentro de las limitaciones normales del autocompletado, no dentro del fallo grave original.

Por qué este workaround es razonable

El cambio no sustituye el helper de Apple ni instala nada extraño.

Seguimos ejecutando iCloudPasswordsExtensionHelper.exe, firmado y proporcionado por Apple.

Lo único que cambia es cómo llega Chrome hasta él.

En lugar de depender de una integración atada a una ruta interna del paquete de WindowsApps, se utiliza el alias estable de Windows:

%LOCALAPPDATA%\Microsoft\WindowsApps\iCloudPasswordsExtensionHelper.exe

Eso además tiene una ventaja práctica: el alias no incluye un número de versión concreto.

¿Habrá que repetirlo tras actualizar iCloud?

En principio, no.

Precisamente una de las ventajas del workaround es que apunta al alias estable de Windows, no a una ruta del tipo:

C:\Program Files\WindowsApps\AppleInc.iCloud_13.4.101.0_x86__...

Si iCloud cambia de versión, Windows debería resolver internamente ese alias hacia la versión nueva del helper.

Solo habría que revisarlo si ocurre una de estas dos cosas:

Apple cambia el nombre del helper o modifica el sistema de Native Messaging.
Una actualización futura recrea correctamente la integración oficial y hace innecesario el override en HKCU.

Mientras funcione, no hay motivo para tocarlo.

Rollback

Si algo sale mal o simplemente se quiere volver al estado anterior, el rollback es directo.

Primero se elimina la clave creada en HKCU:

Remove-Item 'HKCU:\Software\Google\Chrome\NativeMessagingHosts\com.apple.passwordmanager' -Recurse -Force

Y opcionalmente se borra la carpeta que contiene el manifiesto:

Remove-Item "$env:LOCALAPPDATA\iCloudChromeFix" -Recurse -Force

Con eso, Chrome vuelve a depender exclusivamente de la configuración original de Apple en HKLM.

Conclusión

La parte interesante de esta incidencia no es solo que se arreglara iCloud Passwords en Chrome.

Lo realmente útil es el patrón de diagnóstico.

A simple vista parecía un fallo de la extensión.

No lo era.

La aplicación funcionaba, las contraseñas existían, el helper estaba presente y el manifiesto oficial también. El problema estaba una capa por debajo, en la integración entre Chrome y el componente nativo de Apple.

Cuando apareció el código de seis dígitos, quedó claro que el verdadero cuello de botella era el puente Chrome ↔ Native Messaging ↔ iCloud.

Y a veces eso pasa mucho más que lo que nos gusta admitir: no falla la herramienta que vemos, falla la pieza silenciosa que hay justo debajo.