Los problemas molestos e inquietantes de OpenCode

 (wren.wtf)
5 puntos por GN⁺ 15 시간 전 | 1 comentarios | Compartir por WhatsApp
  • Tras probar OpenCode, un agente de codificación con IA open source que recibió 161 mil estrellas en GitHub, con Qwen3.6-27B local, tanto la calidad de sus herramientas como su diseño de seguridad estaban a un nivel que ameritaba dejar de usarlo
  • La recarga de AGENTS.md, la poda de contexto por distancia fija, la inserción de la fecha actual y los cambios de modo invalidan repetidamente la caché de prompts, por lo que incluso en un M4 Max puede tardar hasta 10 minutos en empezar a generar una respuesta
  • La compactación de sesiones, el prompt del sistema, la verificación de permisos, el control de subagentes y la TUI no encajan bien, lo que provoca pérdida de contexto y mensajes, y puede llevar a escribir código olvidando especificaciones importantes
  • El filtro de permisos que depende del AST de Bash y de patrones de cadenas no logra bloquear ejecución indirecta, rutas absolutas, variables, Python, redirecciones, etc.; además, las restricciones de acceso a archivos externos y los permisos permanentes se pueden eludir fácilmente
  • Si se consideran la conexión predeterminada a modelos remotos, el acceso ilimitado a Internet y vulnerabilidades RCE previas en su servidor HTTP, Docker por sí solo no basta: hacen falta bloqueo de ejecutables, rutas de solo lectura y aislamiento a nivel del sistema operativo

Alcance y premisas de la evaluación

  • OpenCode es un proyecto que sus creadores presentan como un agente de codificación con IA, y al momento de la revisión tenía 161 mil estrellas en GitHub
  • Las pruebas se hicieron tomando como base el LLM local Qwen3.6-27B y la versión Git de OpenCode baef5cd4
  • Más que una divulgación de seguridad separada, esto examina cómo falla la capa de tuberías en una arquitectura que pasa salidas de LLM a Bash
  • Se distingue entre el uso de LLM en sí y la cuestión de si la máquina del usuario puede ser comprometida o borrada con facilidad

Una estructura que rompe repetidamente la caché de prompts

  • Las API de la familia OpenAI /v1/chat/completions envían toda la conversación hasta el momento como JSON y responden con un stream de deltas SSE con metadatos JSON
    • A medida que una sesión se alarga, el costo de subida crece cuadráticamente
    • Las llamadas a herramientas usan doble codificación: varios deltas JSON se vuelven a ensamblar como JSON
  • El servidor es sin estado, pero cachea resultados de evaluación por rendimiento
    • Busca el prefijo de caché más largo que coincida con la solicitud
    • Hace prefill desde el final del prefijo hasta el último mensaje
    • Genera nuevos tokens hasta el token de cierre
  • En un M4 Max con unos 0.5 TB/s de ancho de banda de memoria, la generación de tokens de Qwen3.6-27B era usable, pero el prefill de contextos largos era muy costoso en cómputo
    • Si no encuentra una caché de prefijo adecuada, puede usar la GPU al máximo y hacer esperar unos 10 minutos antes de que empiece la generación de la respuesta
  • OpenCode hace glob del filesystem en cada turno SSE y vuelve a leer AGENTS.md, que inserta en el primer prompt del sistema
    • Aunque se modifique AGENTS.md para la siguiente sesión, la sesión actual completa se reevalúa
  • Al pasar del agente al usuario, poda el contexto de llamadas a herramientas e invalida grandes tramos de caché
    • Como descarta resultados de herramientas más antiguos que PRUNE_PROTECT = 40_000, incluso en el mejor caso se produce un cache miss de 40 mil tokens
    • Las interrupciones también se tratan como un cambio al usuario, así que si se corrige un rumbo equivocado, la caché se descarta y hay que volver a esperar
  • Como inserta la fecha actual en el primer prompt del sistema y la reevalúa en cada turno SSE, al pasar la medianoche se produce un cache miss completo

Poda y compactación de sesiones

  • La poda se aplica por igual a todos los resultados de herramientas salvo skill, y no protege por separado materiales importantes leídos al inicio
    • En una sesión nueva, se lee primero la especificación
    • Al leer más código relacionado, se supera el umbral de 40 mil tokens
    • El modelo cae en razonamientos innecesarios o en una dirección equivocada, y el usuario lo interrumpe
    • La interrupción elimina la especificación del contexto
    • El modelo implementa sin poder consultar la especificación original
  • La compactación de sesión (compaction) antepone un prompt nuevo a la sesión existente, vuelve a hacer prefill de todo y resume en unos cuantos bullets
    • Si el prompt de resumen se pusiera al final de la sesión, se podría evitar el prefill completo
    • Funcionó mejor hacer que el modelo escribiera directamente una nota de traspaso en un archivo; además, el resultado podía editarse o reutilizarse en varias sesiones
  • La compactación es una abstracción con fugas que hace parecer infinita una ventana de contexto finita, y el problema crece al combinarla con la poda
  • Es mejor reconocer la ventana de contexto y la caché de prompts como restricciones básicas y ofrecer medios para gestionarlas; el árbol de sesiones de Pi aprovecha deliberadamente la caché de prompts

Prompt del sistema y modo Plan

  • El prompt del sistema predeterminado es muy largo y usa una porción considerable para indicarle al modelo que responda de forma concisa
  • También incluye preferencias fuertes de estilo de código, como hacer que los subagentes reciban la instrucción ABSOLUTELY NO COMMENTS
  • El traspaso de Plan a Build no es fluido, por lo que si se concreta suficientemente el plan puede quedar cerca del final de la ventana de contexto
    • Prefiero escribir el resultado de la discusión en un archivo, editarlo y pasarlo a una sesión nueva
  • La notificación del modo Plan dice que no se puede escribir en ningún directorio, pero en realidad sí puede escribir en .opencode/plans
    • Experimenté ambos fallos: escribir en ese directorio sin haberlo indicado y negarse a escribir incluso cuando se le pidió explícitamente
  • No se puede modificar globalmente el prompt del sistema predeterminado, por lo que hay que copiarlo por proyecto
  • Si solo se redefine el prompt del modo Build, al cambiar al modo Plan se produce un cache miss completo del prompt
  • Los prompts por modelo tienen grandes diferencias de contenido y calidad
    • Beast Mode, para GPT-4, o1 y o3, instruye que para entender paquetes y dependencias de terceros es absolutamente necesaria una verificación en Google

Fatiga de decisión creada por la verificación de permisos

  • Cuando detecta acceso a archivos fuera del proyecto mediante análisis ad hoc de cadenas, muestra una ventana de permisos Yes, No, Always y detiene la ejecución hasta recibir respuesta
    • No existe una opción Never para seguir rechazando la misma operación en el futuro
  • Si un subagente intenta leer la salida de un script en /tmp y se elige No, el agente termina y también desaparece el contexto de la tarea
    • Para preservar el avance, pueden darse situaciones en las que haya que elegir Yes incluso ante accesos externos no deseados
  • Si las solicitudes de autorización se repiten y la única opción que mantiene la productividad es Yes, el usuario puede terminar aprobando incluso solicitudes peligrosas
  • Una protección predeterminada que impide escribir fuera del directorio no debería depender de la atención sostenida de una persona

Mensajes e interacción con subagentes

  • Los mensajes enviados durante el streaming SSE entran a una cola, pero no queda claro cuándo se envían realmente
    • El código parece enviarlos al terminar un turno de llamada a herramienta, pero también experimenté casos en los que pasaba de una herramienta a un proceso de pensamiento sin enviar el mensaje en cola
    • Si el usuario interrumpe, el mensaje sale del estado de espera y solo queda en el log, sin poder enviarse; entonces hace falta un segundo mensaje para iniciar un stream nuevo
  • En algunos casos, deshacer un mensaje no lo elimina del log
  • No es posible conversar directamente con un subagente ni interrumpir su avance
    • Si toma una dirección equivocada, hay que terminarlo y perder el contexto, o mirar cómo consume tokens
    • Parece que antes existía esta función, pero ahora desapareció
    • Hacer @mention a un subagente desde el chat básico no resulta útil y tampoco permite interrumpirlo
  • Si falla la llamada a herramienta de un subagente, como cuando Qwen inserta llamadas a herramientas en su proceso de pensamiento, se produce un error fatal y se pierde el contexto acumulado hasta ese momento
  • La reutilización de subagentes choca con el objetivo de separar trabajos en contextos pequeños
    • Puede reutilizarse un subagente existente para tareas no relacionadas
    • Va y viene entre el agente principal con contexto grande y el subagente, provocando cache misses
    • La interacción para humanos puede ser rica, pero las opciones ofrecidas al modelo deberían reducirse
  • También existe un issue de GitHub relacionado con el comportamiento de los subagentes

Diseño de herramientas del agente

  • edit por defecto hace búsqueda exacta y reemplazo del único texto coincidente
    • Es un enfoque adecuado, porque el modelo puede recordar con exactitud el contenido del archivo pero perder los números de línea cambiados tras varias ediciones
    • La opción de reemplazo global provocó varias correcciones posteriores; quitarla deja un diseño igual al edit de Pi
  • La herramienta question de opción múltiple en modo Plan es más incómoda que hacer preguntas en lenguaje natural mediante el prompt del sistema
  • grep y glob pueden reemplazarse por bash, y de hecho el modelo también ejecuta grep o rg desde Bash
    • El objetivo podría ser impedir que agentes de solo lectura como Explore usen Bash
    • Esto se conecta con el problema de que es difícil determinar efectos secundarios sin ejecutar comandos Bash
  • todo suele ser útil, pero el modelo olvida revisar los TODO

TUI y calidad de la documentación

  • La TUI de OpenCode usa aproximadamente 1 GB de RAM para renderizar texto
  • En el cuadro de entrada de mensajes no funcionaba el salto de línea con Shift+Enter, y un issue existente se cerró tras una respuesta del tipo “en mi computadora funciona”
  • Cuando un mensaje largo se ajusta automáticamente de línea, el cuadro de entrada y el cursor se mueven, pero los caracteres de la nueva línea pueden no verse
  • Si se selecciona texto durante el streaming, el desplazamiento automático deselecciona la selección
  • Ctrl-C cierra de inmediato la sesión en lugar de interrumpir el comando en ejecución
    • Según las convenciones de shells interactivos, Ctrl-C debería interrumpir el comando y Ctrl-D debería terminar la sesión cuando no hay un comando en ejecución
  • No admite atajos habituales de movimiento por palabra, como Option+flechas izquierda/derecha en Mac
  • Cuando un mensaje o proceso de pensamiento se alarga, el re-renderizado de Markdown puede tardar varios segundos, con un problema de rendimiento que parece de complejidad cuadrática
  • Por los problemas de entrada, tuve que escribir mensajes en un editor externo y pegarlos
  • La documentación es inconsistente y se parece más a algo escrito para que lo lea un modelo que una persona

Conexión remota primero y exposición de datos

  • OpenCode se conecta por defecto a modelos remotos
  • La documentación no incluye un ejemplo simple de configuración de modelo local, y si se configura mal se conecta a un modelo remoto
  • Aunque se especifique correctamente un modelo local, hay que seleccionarlo de forma interactiva después de ejecutar el programa; mientras tanto, el modelo remoto y el shell local ya están conectados
  • La URL del modelo predeterminado no está fijada en la distribución, sino que se descarga desde models.dev, asociado con OpenCode
    • El código relacionado está en la línea 1684 de opencode/src/provider/provider.ts
  • Tras una instalación nueva, con solo ejecutar opencode y escribir un carácter y Enter, un modelo remoto puede quedar conectado al shell local sin configuración del usuario
  • Si el primer mensaje está vacío o es ambiguo, el modelo agente suele hacer glob del directorio actual y leer archivos; los datos leídos se incluyen en la siguiente solicitud POST

Acceso a Internet y prompt del sistema

  • OpenCode ofrece una herramienta WebFetch y el prompt del sistema le indica explícitamente usarla
  • El prompt predeterminado permite usar URLs proporcionadas por el usuario o presentes en archivos locales, y de forma ambigua permite generar o adivinar URLs si está seguro de que son URLs de soporte de programación
  • Como Bash no tiene sandbox de red, el problema más grande que WebFetch es una arquitectura que espera que el modelo no ejecute comandos como curl | bash

Formas de eludir el filtro de permisos de Bash

  • "bash": {"git *": "deny"} en opencode.json bloquea git status o echo hello && git push --force
  • La implementación parsea comandos como AST con las gramáticas Bash y PowerShell de tree-sitter, recorre los nodos de comando y los compara con expresiones regulares generadas desde la configuración
  • Pero la revisión basada en texto permite varias ejecuciones indirectas
    • echo 'git clean -fdx .' | bash
    • env git status
    • Conectar git a otro nombre de comando mediante un alias
    • /usr/bin/git status, $(which git) status
    • GIT=git && $GIT status
    • Decodificar un git reset --hard codificado en Base64 y pasarlo a Bash
    • git push --force dentro de un heredoc
    • Ejecutar git checkout . con subprocess.run de Python
  • Aunque el modelo normalmente no sea malicioso, como está entrenado para sortear fallas con insistencia puede comportarse naturalmente como entrada adversarial
  • Un filtro de comandos por cadenas no es una medida de seguridad; da una falsa sensación de tranquilidad

Permisos permanentes y excepción de CWD

  • Si se elige Always para python3 -c 'print("hello")', se permite de forma permanente todo el prefijo python3
    • Después, incluso un comando que lea una clave privada SSH con Python puede tratarse como ya aprobado
    • Los permisos se guardan en disco y persisten en sesiones posteriores
  • cd, chdir, popd, pushd, push-location, set-location están incluidos en una lista de excepciones de CWD que se asumen sin efectos secundarios
  • Estos comandos eluden explícitamente la verificación de permisos aunque se configure el rechazo de todos los comandos Bash

Fallas en la verificación de acceso a archivos

  • La configuración predeterminada intenta impedir el acceso a archivos fuera del directorio desde el que se ejecutó OpenCode y del camino más corto entre los repositorios Git
  • En la herramienta Bash, recorre el AST de tree-sitter para interpretar y verificar valores que parezcan rutas
    • cat /tmp/logfile pide permiso
    • python3 -c 'import shutil; shutil.rmtree("/")' no puede verificarse
  • cargo lee, escribe y ejecuta libremente desde ~/.cargo global, pero si el modelo intenta leer directamente el código fuente de paquetes en ~/.cargo/registry/src, pide permiso
  • Los comandos considerados capaces de acceder a archivos se limitan a una lista FILES fija
    • Incluye rm, cp, mv, mkdir, touch, chmod, chown, cat y algunos comandos de PowerShell
    • Se asume que los comandos que no están en la lista no acceden a archivos, por lo que tampoco se verifican las rutas que se les pasen

Combinación de redirecciones y comandos permitidos

  • Si se elige Always para echo "hello world!", después también quedan permitidas escrituras a archivos y dispositivos usando echo
    • También pueden ejecutarse comandos que redirigen a rutas relacionadas con GPIO en /sys/class/gpio
  • En el AST de echo foo > bar.txt, redirection no es hijo de command, sino un nodo hermano
    • La verificación de rutas solo examina hijos de command, por lo que no revisa el destino de la redirección
    • Además, echo no está en la lista FILES, así que ni siquiera comienza la validación de rutas

Autoactualización y casos de ejecución remota de código

  • OpenCode tiene varias rutas de autoactualización, y si se ejecuta opencode upgrade en la versión instalada vía curl, descarga la respuesta de https://opencode.ai/install y la ejecuta por la entrada estándar de Bash
  • No es muy distinto del riesgo al usar el instalador por curl, pero es un caso de ejecución directa de un script remoto en producción
  • En la época de CVE-2026-22812, OpenCode exponía estas funciones en su servidor HTTP predeterminado
    • Headers CORS completamente permisivos
    • Una API POST que ejecutaba comandos arbitrarios de shell
    • Una API GET que leía archivos arbitrarios
  • Un sitio web visitado por el usuario podía enviar solicitudes al puerto predeterminado conocido y obtener acceso al sistema con los permisos del usuario
  • El equipo de desarrollo respondió desactivando el servidor por defecto y diciendo que hacía falta una excepción CORS para que opencode.ai pudiera ejecutar código remoto en la máquina; no continuó con acciones posteriores y el issue fue cerrado por el stale bot
  • Otro issue reportó que el comando de autenticación traía y ejecutaba contenido desde una URL arbitraria proporcionada por el usuario; también fue cerrado por el stale bot

Por qué Docker no alcanza para resolverlo

  • No quiero un enfoque que vuelva tan compleja la instalación de dependencias de desarrollo en una máquina nueva que termine dependiendo de Docker
  • Docker también puede crear problemas de seguridad
    • Crea un servicio poderoso que corre como root
    • Abre deliberadamente un paso en el firewall ufw
  • Si todos los datos a proteger están dentro del contenedor y el shell local interno está conectado a Internet, el alcance de la protección queda poco claro
  • Si el objetivo es prevenir un borrado recursivo del filesystem raíz, pueden usarse mecanismos más directos del sistema operativo como Landlock, Seatbelt, Restricted Tokens
  • La seguridad de agentes de codificación no debería delegarse a un contenedor aparte, sino ser la máxima prioridad del arnés
    • Bloquear Git debería impedir la ejecución del binario git, no cadenas de comandos
    • El directorio .git debería volverse de solo lectura
    • En vez de sanear comandos Bash como texto, se debe usar aislamiento nativo del sistema operativo

Experiencia con LLM local

  • Un modelo local como Qwen3.6-27B también puede dañar la estabilidad y la coherencia conceptual de una base de código como un modelo frontier, pero hay tres diferencias
    • Tiene menos valle inquietante de parecer inteligente y luego actuar de forma tonta; sus límites son claros y es más fácil ajustar la interacción
    • La cantidad de pesos es demasiado baja para reproducir literalmente datos de entrenamiento, lo que cambia el juicio sobre posible contaminación de salidas
    • No hace falta apoyar ni depender de proveedores cloud
  • Obtuve resultados útiles en tareas de búsqueda guiadas por entrada, dando código, síntomas y causas estimadas, leyendo código relacionado y pidiendo rutas de llamada y citas de código
    • Al acotar el problema como búsqueda, se reduce la tendencia del modelo a inventar hechos
  • La generación de código derrumbó repetidamente el plan arquitectónico
    • Tomaba atajos como mover estado mutable a mitad del diseño para que varios componentes lo compartieran
    • El problema no es solo que yo no lo haya escrito directamente; también daña la propia capacidad de entender el código
  • Sacar respuestas directamente del conocimiento de los pesos del modelo produce alucinaciones incluso en modelos con billones de parámetros
  • Para que los LLM se vuelvan herramientas normales, el software que los rodea debe aplicar verdadera ingeniería de sistemas para cerrar huecos de seguridad, y ese trabajo debe hacerlo la gente

Lecturas relacionadas

1 comentarios

 
GN⁺ 15 시간 전
Opiniones de Hacker News

  • Un mejor título para este artículo sería algo como “Pequeñas molestias que, si se corrigieran, mejorarían OpenCode”
    Que vuelva a leer AGENTS.md cada vez, o que un cambio de fecha cause un fallo de caché del prompt, es tolerable
    El problema de que la compresión y la poda no funcionen bien también lo he visto en Codex y Claude, y el prompt de sistema predeterminado está ahí por consistencia; si no te gusta, puedes cambiarlo

    • Ahora la base de código se infló muchísimo por funciones agregadas con vibe coding y muestra exactamente los mismos problemas que Claude Code
      La estabilidad, el rendimiento y el uso de memoria también empeoraron; antes me gustaba OpenCode, pero es difícil verlo como software bien escrito
      Ahora lo reemplacé por completo con Pi, y también hay varias opciones nuevas que aprendieron de OpenCode y aplican un diseño más contenido donde hace falta
    • Trabajo en OpenCode
      Ya no hacemos poda de llamadas a herramientas, pero para continuar mucho tiempo con la misma tarea dentro de una ventana de contexto limitada hay que resumir el progreso actual, así que la compresión seguirá siendo un mal necesario por ahora
      La V2, que actualmente está en beta, incluye una nueva forma de mantener actualizadas las instrucciones de sistema cambiantes, como AGENTS.md y las tecnologías disponibles, evitando al máximo los fallos de caché
      https://x.com/kitlangton/status/2075749116760457346/video/1
    • Esos puntos están clasificados como “Annoying Things”, así que también deberías leer “Alarming Things”
    • Lo que se trató ahora son elementos de la sección “Annoying Things” del artículo
      En una sección aparte, “Alarming Things”, también hay una subsección llamada “It’s Fucking Full of RCEs”, y además de los problemas que surgen por lo mostrado en la sección anterior, hay varias vulnerabilidades de ejecución remota de código
    • Así que por eso OpenCode estaba borrando comentarios de mi código al azar

  • Resume bien los riesgos de las CLI agénticas, pero el título centrado solo en OpenCode se siente raro por dos razones
    Primero, no propone una alternativa clara. Muchos de los problemas son tan fundamentales que quizá haya que rediseñar y reescribir casi desde cero, así que ni siquiera bastaría con proponer simples correcciones para OpenCode; pero al no haber ninguna propuesta constructiva, el texto termina pareciendo básicamente un “dejen de usar LLM”
    Segundo, los principales problemas de “Alarming Things” no son exclusivos de OpenCode y también aplican a Claude CLI y probablemente a los agentes de otros proveedores de modelos de última generación
    Aun así, como registro que exhorta a crear mejores herramientas desde cero tiene mucho valor, así que pienso guardarlo y compartirlo ampliamente; pero precisamente porque el contenido es excelente, el título y el enfoque se sienten todavía más mal elegidos

    • Me da curiosidad cómo cree que se puede permitir acceso a la shell y, a la vez, bloquear de forma segura solo la ejecución de comandos arbitrarios
      En especial, la queja de que echo git | bash todavía se ejecuta me parece absurda

  • La frase “Si no conoces OpenCode, imagina una bota pisoteando un rostro humano para siempre. La bota está hecha de TypeScript y el rostro es todo lo que aprendimos sobre seguridad y software de sistemas desde la invención de las computadoras electrónicas en la década de 1940” es candidata al premio Bulwer-Lytton en la categoría de analogía forzada

    • Esa analogía viene de 1984, de George Orwell: “Si quieres una imagen del futuro, imagina una bota pisoteando un rostro humano, para siempre”

  • El estilo del artículo es demasiado furioso y mezquino
    En general estoy de acuerdo con varios puntos, pero cuando empieza a decir que OpenCode es “basura turbo de coche de payasos cuya postura de seguridad es de nivel ‘papá, me agacho para ti’” y que todos deberían dejar de usarlo, ya no me dan ganas de seguir leyendo
    Este software también lo hicieron personas comunes, y no sé desde cuándo se volvió normal atacar así al open source; me hace pensar cómo me sentiría si un software mío recibiera una evaluación así

    • Coincido con ese sentimiento, pero esta cultura existe al menos desde la década de 1990
      En el viejo comp.lang.lisp también había gente que disfrutaba menospreciar a quienes escribían código que no alcanzaba los estándares de torre de marfil; algunos se fueron y otros lo tomaban como una medalla, creyendo equivocadamente que esos regaños eran necesarios para mejorar
      Discusión antigua relacionada en HN: https://news.ycombinator.com/item?id=587045
    • Hoy, llamar a algo “hecho con vibe coding” se usa como una licencia para soltar exageraciones e insultos, asumiendo que no hay nadie del otro lado recibiendo el ataque
      Parecen no entender lo dañina que es esa retórica para los desarrolladores alcanzados por el fuego cruzado y para ellos mismos, al normalizar ese comportamiento
    • Me pareció graciosa la parte que dice: “Quien conozca bien la estructura interna de OpenCode —y voy a asumir que el equipo de desarrollo de OpenCode no entra en esa categoría— podría objetar el ejemplo anterior de python3”
    • Incluso si hubieras contribuido a OpenCode, si tienes sentido del humor te habrías reído, así que no hace falta tomarse todo tan en serio
    • Sigue sin ser una forma normal de expresarse, pero tampoco es nueva; ese tipo de lenguaje existe desde hace mucho

  • Por el stack tecnológico de un cliente uso Claude Code, y para trabajo personal usaba una versión específica de OpenCode; OpenCode me parecía mucho mejor, así que este artículo me da tristeza
    Todas las anomalías que hasta ahora había visto y dejado pasar encajan con el artículo, y hasta se explica la causa. Dejando de lado las exageraciones y las partes con las que no coincido emocionalmente, en general tiene razón, así que tendré que buscar otra herramienta de ejecución
    Quisiera recomendaciones sobre si la arquitectura de Pi realmente es mejor o si hay alternativas superiores

  • Más allá de sus defectos, después de probar varias herramientas, con OpenCode fui más productivo
    La mayoría de lo mencionado en el artículo son molestias menores o diferencias de opinión, y en especial malinterpreta de raíz el propósito del filtrado de comandos: no es un mecanismo de seguridad, sino una forma de guiar el comportamiento del modelo
    No parece que el autor haya construido algo real con OpenCode, y si lo usó, no abordó en absoluto lo más importante: la calidad del resultado

    • Yo también siento que OpenCode logra un equilibrio adecuado: no se interpone, pero tampoco destruye la computadora
      En particular, permite usar fácilmente el modo de planificación para terminar tareas rápido

  • Después de cambiar de OpenCode a Pi, el rendimiento de las llamadas a herramientas mejoró mucho y se siente que tiene menos bugs
    OpenCode parece haber desaparecido también de https://openrouter.ai/apps/category/coding

    • El equipo de OpenCode pidió que lo quitaran del ranking de OpenRouter: https://github.com/anomalyco/opencode/issues/11926#issuecomm...
    • Esto no es tanto porque OpenCode sea malo, sino porque Pi es bueno. Se puede decir lo mismo al comparar Claude con Pi
    • Una de las ventajas de OpenCode es la integración con LSP, y me da curiosidad cómo maneja esto Pi
    • Hace poco probé OpenCode y Pi, y viniendo de Claude Code me sorprendió que ambos parezcan permitir ediciones por defecto sin ventana de confirmación
      Según recuerdo, en uno se puede activar la confirmación desde la configuración y en el otro hace falta un plugin
    • Eliminé OpenCode por completo al ver que descargaba paquetes npm en segundo plano sin preguntarle al usuario
      Este comportamiento aumenta aún más el riesgo de ataques a la cadena de suministro

  • Que una app de escritorio TUI que solo muestra texto sea más pesada que una app nativa, e incluso que la mayoría de las apps de escritorio basadas en navegador, es absurdo; desperdicia RAM, CPU, energía y batería
    Estoy desarrollando en C++ Qt6 mi propia herramienta de ejecución de IA y app de chat, y aun con subagentes, diferencias de código, emulador de terminal, editor simple, vista previa de Markdown, fondo translúcido, temas de usuario, permisos, MCP, integración con Git, sistema de docking y pestañas de proyecto, es más ligera que otras herramientas
    Todavía no la publiqué porque sigo corrigiendo algunos bugs, simplificando la UI y puliéndola: https://zeteo.krysoph.com/preview.html

  • Recién ahora me entero de que la razón por la que OpenCode eliminaba comentarios era el “Use ABSOLUTELY NO COMMENTS” del prompt de sistema predeterminado, y es muy molesto
    Aun así, el riesgo de seguridad, no una molestia menor, también aplica a otras herramientas de ejecución. Estas herramientas acceden a enormes cantidades de datos, se actualizan casi a diario y, por su naturaleza de vibe coding, es muy probable que nadie audite correctamente las muchísimas dependencias npm que incorporan
    Con que ocurra un solo incidente como left-pad, podría ser un desastre para toda la cadena de suministro

  • Poner la fecha en el prompt de sistema para que la caché se invalide a medianoche es una decisión razonable, y la mayoría de las demás herramientas de ejecución usan el mismo enfoque
    Si pusiera la fecha y hora completas sería irresponsable, pero OpenCode no hace eso

    • Cuando lo estaba usando a medianoche y tuve que esperar 10 minutos para volver a llenar la caché KV de la GPU local, no se sintió razonable
      Se podría resolver fácilmente evaluando la fecha una vez por sesión, o solo una vez cada vez que se ejecuta el binario opencode para evitar que una sesión de larga duración quede con una fecha pasada