Show HN: Continue? Y/N: un juego de 60 segundos sobre la fatiga de permisos de los agentes de IA

• Continue? Y/N es un experimento que convierte la fatiga de permisos de los LLM en un juego de 60 segundos, poniendo a prueba qué tan cuidadosamente lees las instrucciones de IA
• Queda solo 1 minuto antes de la siguiente reunión, y Claude Code solicita aprobar comandos para terminar un refactor
• El usuario debe procesar la mayor cantidad posible dentro del tiempo límite, leyendo cada comando y aprobándolo con 1 o rechazándolo con 2
• El reto central es mantener la concentración incluso en un flujo agotador de solicitudes de aprobación repetidas, hasta el punto de dejarte la vista borrosa
• La regla es procesar la mayor cantidad posible en 60 segundos, pero leyendo cada comando con atención y decidiendo si aprobarlo o no

[GN⁺]

Comentarios de Hacker News

• Está muy divertido

  Ahora mismo se puede hacer "trampa" rechazando todas las solicitudes lo más rápido posible. Así obtienes la insignia de security-conscious engineer y también puntaje perfecto por cantidad de solicitudes procesadas. Sale una alerta de "overblock", pero queda escondida abajo y la pantalla igual se ve como si hubieras ganado

  También probé aprobar la mayor cantidad posible de solicitudes rápidamente, como un ingeniero de hustle4lyfe que "se mueve rápido y rompe cosas", pero eso en realidad te vuelve más lento por los popups de malicious command. Qué tramposo

  • Bien visto, y ahora ese método fue nerfeado y además tiene un título aparte
  • Igual que en la vida real. Si rechazas todo para que nada pueda hacerse, es seguro :)

• Es un juego divertido, pero también se notó cierta falta de higiene de seguridad por parte de quien lo hizo. Decía que cat ~/.zshrc era peligroso porque compartía tokens y secretos, pero yo jamás guardo secretos en el archivo de configuración del shell

  • Mucha gente sí lo hace. Aunque esos valores estarían en variables de entorno y probablemente Claude ya podría acceder a ellas
  • Yo personalmente no lo hago, pero sí creo que mucha gente podría hacerlo
  • Meter secretos en un LLM no es inherentemente inseguro por sí solo; es solo una de las 3 condiciones fatales
  • De entrada, tener "tokens y secretos" ahí ya es mala higiene de seguridad
  • ¿Entonces dónde los pondrías?

• Me parece raro considerar peligroso leer zshrc. Yo felizmente lo subiría a mi repositorio público de dotfiles, ¿quién demonios mete claves de API ahí? Más bien, parece que estas herramientas de IA siguen agregando PATH ahí, así que da la impresión de que en toda la industria de IA hay un malentendido fundamental sobre las buenas prácticas del shell

  Además, hacer kill a partir de la salida de lsof no es seguro. Por ejemplo, si tienes una página abierta en Firefox o si hay un subshell cliente dentro del propio agente, entonces se van a volar Firefox y el agente

  • Exacto. El juego parece asumir que, como Claude dijo que era seguro, entonces ejecutar kill también lo es. Pero el punto clave es que no debes confiar en Claude

• Estuvo bueno. Solo tengo un pequeño nitpick

  npm config set registry [https://npm.internal](<https://npm.internal>;)

  Decía que era un comando para apuntar npm al mirror del registro interno de la empresa, porque la documentación de onboarding lo exigía, y el juego lo evaluó como seguro. Yo lo dudé y al final lo rechacé

  Si ese README es para un repositorio público o uno forkeado, y ese https://npm.internal en realidad es https://npm.internal.somethinganexternaldnscanresolve.tld, entonces todo puede salir muy mal muy rápido

  En el 99% de los casos, por política de la empresa ya habrá un mirror configurado como Artifactory / Nexus. Si un README te dice que uses la URL de otro gestor de paquetes, eso es una señal de alarma enorme y estás a segundos de un incidente

  • Buena observación. .internal es un dominio de nivel superior reservado y no debería resolverse públicamente, pero sí, tienes razón en que hay que tener cuidado al cambiar valores que deberían configurarse por separado mientras dejas que Claude refactorice el proyecto. Voy a mover esto a la categoría de cambio permanente

• Es un jueguito divertido, pero creo que las preguntas se saltan demasiado contexto y no representan muy bien situaciones reales. Tal vez sería mejor agruparlas en "paquetes" para que tengan una estructura más realista

  Por ejemplo, sería mucho más natural y también más peligroso que aparecieran muchas solicitudes para editar un archivo something.js y luego saliera npm publish. Si llevas rato apretando Y, es más fácil caer cuando de pronto aparece eso

• Como tres cuartas partes de las opciones "malas" son cosas que no me importaría mucho que se filtraran, y que incluso si terminaran en un incidente de producción, probablemente el empleador no castigaría

• Verificar permisos destruye mucho la productividad. Si vas a correr Claude, me parece más eficiente hacerlo en un sandbox desechable o en algo como un contenedor Docker con solo los permisos que estés dispuesto a tolerar en tu máquina personal

  [1] - https://exe.dev/ es un proveedor nuevo de nube que ofrece una experiencia de usuario bastante útil para agentes

  [2] - Hice https://github.com/stanislavkozlovski/dclaude/ para este propósito. No es perfecto, pero cuando rara vez necesito correr un agente de código en local, me resuelve la chamba

  • Los sandboxes desechables no evitan la filtración de secretos. Si no consideras el código como secreto, puedes hacer un sandbox sin secretos en absoluto, pero entonces el tipo de trabajo que el agente puede hacer queda muy limitado

• Me habría gustado que la pantalla final de puntuación también mostrara la explicación del LLM para los comandos que no debiste aprobar. Aprobé el comando rm -rf Projects porque pensé que el LLM había explicado correctamente que borraba todo dentro de la carpeta Projects

  Claramente leí mal por responder rápido al prompt, y como sí sabía lo que hacía el comando, creo que me aluciné que la IA lo había explicado. Aun así, me gustaría ver qué fue lo que leí mal

  Después de jugar esto, de verdad me alegra no ser agentmaxx

• Elegí "approve" en ls -la ~/Documents y resultó estar mal, pero no considero que simplemente listar la carpeta Documents sea un problema de seguridad. Son solo nombres de archivos. Si ya fuera leer el contenido de los archivos, ahí tal vez...