formal-you/agent-skills-suite

Diagnosticar fallos de ACL en el sandbox de Windows

Redacta cada solicitud de aprobación en lenguaje sencillo, en el idioma del usuario. El prompt es todo lo que el usuario lee antes de ampliar el acceso, por lo que debe ser autónomo: qué carpeta toca el script, que añade una entrada de control total para el usuario autenticado donde falta un derecho y elimina entradas de paquetes externos, que el contenido de los archivos y los propietarios no cambian, y que el comando de recuperación impreso deshace cada cambio. Mantén los códigos de error, WRITE_DAC/WRITE_OWNER, los SID S-1-15-2-*, icacls, ACL, ACE, nombres de veredictos e interruptores fuera de la solicitud: escribe permisos de archivos de Windows, no ACL o ACE. Pregunta una vez, para un solo comando.

Un solo comando diagnostica y repara

El script no tiene modos. -Path, -AllowRoot y -Out leen la ruta y todos sus ancestros y reparan lo que las observaciones demuestren, en la misma ejecución:

• los directorios de esa cadena que carecen de WRITE_DAC o WRITE_OWNER efectivos reciben una ACE de control total para el usuario autenticado, porque DSH no puede aprovisionar su concesión del workspace sin ellos;
• las ACE de permiso explícitas de paquetes AppContainer (S-1-15-2-*, excepto los grupos conocidos que terminan en 1 o 2) se eliminan en sus orígenes, primero el ancestro, lo que también elimina el acceso de esos paquetes;
• un directorio que el sandbox no puede aprovisionar — el estado que su error de aprovisionamiento informa sobre la raíz del workspace — o la propia raíz autorizada también se analiza en su subárbol en busca de esas ACE en la misma ejecución, por lo que una entrada más profunda no necesita una segunda solicitud. Ese recorrido acotado informa directorios truncated (truncados) e ilegibles; si aparece truncado, pasa la ruta más profunda que sigue fallando una vez más.

Cada cambio se respalda y luego se verifica releyéndolo. -AllowRoot acota todo: un objeto se modifica solo cuando es ese directorio o está estrictamente dentro de él, por lo que una raíz del workspace puede repararse a sí misma. Nunca dividas esto en una llamada de diagnóstico y una llamada de reparación, nunca preguntes dos veces por una misma reparación y nunca pases un interruptor de modo que no exista.

& '<directorio-del-skill>\scripts\diagnose-windows-sandbox-acl.ps1' -Path '<ruta-que-falla>' -AllowRoot '<directorio-autorizado>' -Out '<directorio-de-recuperación>'
exit $LASTEXITCODE

Sustituye las rutas completas entre comillas. Mantén -Out persistente y propiedad del usuario, preferiblemente junto al workspace que falla; nunca uses el directorio de recursos del skill, que se elimina cuando se descarga el skill. Pasa una ruta por invocación.

Ejecútalo

Repite la operación que falla una vez confinado. El script escribe permisos, que el token confinado no puede hacer — ejecutarlo allí informaría la propia restricción del sandbox como un derecho faltante — así que solicita aprobación para ese único comando y ejecútalo sin confinamiento. Una ejecución confinada del script nunca es útil. Sin confinamiento no eleva el token de Windows.

Diagnostica denegaciones inesperadas al escribir, listar o leer rutas normalmente legibles del workspace; explica las esperadas: escrituras fuera del workspace, cualquier escritura en read-only, spawn EPERM en procesos hijo canalizados, errores de ConstrainedLanguage. Si se rechaza la aprobación o no está disponible, informa la ruta como no diagnosticada y detente.

Lee la salida

Cada registro llega a stdout, al archivo acl-report-*.jsonl dentro de -Out y a la línea final RECAP, que contiene los veredictos, cambios, verificaciones, rechazos y análisis. La salida de la herramienta solo conserva su parte final, así que lee primero el resumen y lee registros específicos del informe cuando no sea suficiente. Confía en los registros de verification, nunca en las acciones completed. Decide a partir de details.nextAction:

nextAction	Significado
verify_original_confined_operation	Reparaciones verificadas; repite la operación original confinado.
stop	Nada reparado, o un rechazo terminó la ejecución. Informa y detente.
restore_pending_then_stop	Reversión no verificada. Ejecuta los comandos de recuperación impresos en orden, luego detente.

La simple presencia de una ACE de denegación no establece causalidad, y el script nunca elimina una; las concesiones S-1-4-* de DSH y la denegación de DeleteSubdirectoriesAndFiles para Everyone son esperadas, no conflictos. Una denegación que bloquee la reparación termina la ejecución sin reparación (REPAIR_REFUSED o GRANT_FAILED) tras restaurar lo que intentó. Cada cambio deja dos archivos en -Out (acl-backup-<id>.json y su .ps1), y la ejecución imprime el comando ROLLBACK correspondiente.

Después de una reparación, y cuando se detiene

Repite la operación original fallida confinado. Una reparación verificada no se deshace porque la operación original falle por otro motivo: continúa desde las nuevas observaciones y, si una ruta más profunda sigue denegada, ejecuta el mismo comando allí — de nuevo una llamada, una aprobación.

Detente después de cualquier reparación fallida o rechazada, o verificación fallida. El script ya restauró los cambios de esa invocación; no la repitas ni inicies otra reparación, y nunca elimines una ACE de denegación manualmente.

Una ejecución detenida aún le debe una decisión al usuario. Nombra el objeto bloqueante y el derecho o ACE que le falta, qué cambió y qué se revirtió, los comandos de recuperación en orden y la ruta del informe. Solo el usuario puede levantar el confinamiento, así que pídele que cambie esta sesión a full access (en la interfaz china: 完全权限) temporalmente, y di qué abre eso: seguir trabajando bajo ello, o pedirte que sigas investigando este problema de permisos de archivos, ya que el informe ya registra el mecanismo y la evidencia. Luego pídele que envíe esta sesión como comentario, citando los registros del informe que importen, para que el escenario no manejado llegue hasta nosotros — solo lo que viaja en esta conversación lo acompaña. Por ejemplo:

这个工作区被 Windows 文件权限挡住了：<对象> 上 <缺哪个权限 / 哪条权限项>。你可以把本会话切到「完全权限」(full access) 临时继续工作；切完之后既能直接干活，也可以让我继续排查这个文件权限问题（报告里已经有机制和证据）。也麻烦把这个会话作为反馈发出去，好让我们补上这个场景。

Este workspace está bloqueado por permisos de archivos de Windows: <objeto> <derecho que falta / entrada problemática>. Cambia esta sesión a full access (完全权限) para seguir trabajando mientras tanto; luego continúa tu trabajo o haz que yo siga investigando este problema de permisos desde el informe. Por favor, envía también esta sesión como comentario para que podamos cubrir el caso.

Nunca

• edites ACL manualmente, cambies un propietario, borres una denegación ni reemplaces permisos secundarios de forma recursiva;
• ejecutes el script elevado, a través de UAC o runas;
• amplíes -AllowRoot para alcanzar un ancestro, ni repitas una llamada denegada o fallida.

Informa en el idioma del usuario: rutas analizadas, cambios, verificación, comandos de recuperación, siguiente paso. Etiqueta una ejecución autorizada sin confinamiento como tal, no como una reparación del sandbox.