bug(mcp): the 0600 guarantee on ~/.claude.json does not hold on Windows (chmod sets no DACL)

[Denver2828]

Pre-flight Checks

• I have searched existing issues and this is not a duplicate
• I understand this issue needs status:approved before a PR can be opened

Bug Description

La explicacion simple: en Linux, "0600" es un candado que dice "solo el dueño puede leer esto". En Windows ese candado no existe con la misma llave.. el sistema usa otro mecanismo (ACLs), y la funcion que en Linux pone el candado, en Windows basicamente no hace nada. Entonces prometemos un candado que en Windows no se esta poniendo.

Lo tecnico: ~/.claude.json carga la sesion OAuth, y el PR #1909 fuerza os.Chmod(path, 0o600) tras cada escritura. En Windows, os.Chmod solo alterna el bit read-only de FAT/NTFS.. no establece un DACL restrictivo. Go ademas reporta el modo de NTFS como 0666, por lo que los tests de modo llevan guard runtime.GOOS != "windows": la garantia queda sin enforcement y sin cobertura en la plataforma donde mas usuarios de gentle-ai hay. Señalado por @dnlrsls en la review del PR #1909.

En la practica el riesgo es moderado: el perfil de usuario de Windows ya restringe el acceso de otros usuarios al home. Pero si la garantia se promete, deberia ser real o estar documentada como best-effort por plataforma.

Steps to Reproduce

1. En Windows, correr un install/sync que escriba ~/.claude.json
2. icacls %USERPROFILE%\.claude.json.. el DACL es el heredado del perfil, no uno restrictivo equivalente a 0600
3. Los tests de modo se saltean en Windows (runtime.GOOS != "windows")

Expected Behavior

Una de dos, decidida por maintainers:

1. Enforcement real en Windows: establecer un DACL restrictivo (solo el SID del usuario) via golang.org/x/sys/windows, con test de regresion en la lane de Windows del CI.
2. Best-effort documentado: dejar constancia en el codigo y la doc de que 0600 aplica a plataformas POSIX y que en Windows la proteccion es la del perfil de usuario.

Actual Behavior

La promesa de 0600 existe en el codigo pero en Windows no cambia ningun permiso efectivo.

Operating System

Windows

Agent / Client

Claude Code

Shell

bash (Git Bash)

[Denver2828]

Vine con las dos opciones ya implementadas y probadas en Windows real, para que la decision sea solo elegir:

Opcion 1.. enforcement real (branch fix/2009-windows-dacl): DACL protegido post-write via golang.org/x/sys/windows (que el repo ya usa para los locks), trustees solo owner + SYSTEM + Administrators.. el mismo trust set que acepta Win32-OpenSSH para claves privadas.. con herencia deshabilitada. Se re-aplica tambien tras el rewrite del uninstall (el rename atomico pisa el ACL anterior). Test de regresion que corre en la lane de Windows y verifica el DACL completo. Evidencia en mi maquina (Windows 11, NTFS):

> icacls .claude.json
DESKTOP-XXXXXXX\Dario28:(F)
NT AUTHORITY\SYSTEM:(F)
BUILTIN\Administradores:(F)

Sin Users, sin Everyone, sin herencia. En POSIX queda el chmod 0600 de siempre.

Opcion 2.. best-effort documentado (branch fix/2009-windows-besteffort): deja constancia en el punto de enforcement de que el 0600 es real en POSIX y en Windows la proteccion es la del perfil de usaurio. Cambio de comentarios, cero riesgo.

Mi voto es la opcion 1: si prometemos el candado, que sea un candado de verdad. Pero cualquiera de las dos esta a un PR de distancia apenas este issue tenga status:approved.