Por que parar de usar OpenCode, segundo usuário

O que é OpenCode e por que o autor o rejeita

OpenCode é um agente de codificação open-source com 161k estrelas no GitHub, descrito como uma ferramenta que conecta LLMs a um shell local. O autor, que testou a ferramenta com um modelo local (Qwen3.6-27B em M4 Max), conclui que ela é fundamentalmente insegura e mal projetada, dividindo suas críticas em duas categorias: problemas irritantes e problemas alarmantes.

Problemas de usabilidade e desempenho

O sistema de prompt cache é constantemente invalidado por decisões de design questionáveis: o AGENTS.md é relido a cada turno SSE, a data atual é injetada no system prompt (causando cache miss à meia-noite), e o pruning descarta resultados de tool calls além de um limite fixo de 40k tokens. Isso significa que, em hardware local, o usuário pode esperar até 10 minutos de prefill entre respostas. O mecanismo de compaction força um prefill completo da sessão apenas para gerar 5 bullet points. A interação com subagentes é quebrada: não é possível redirecioná-los, e falhas em tool calls são fatais, perdendo todo o contexto. A TUI consome 1GB de RAM para renderizar texto, tem bugs de cursor, autoscroll que destrói seleções, e ^C fecha a sessão instantaneamente em vez de interromper o comando.

Falhas de segurança graves

O sistema de permissões de bash é baseado em parsing textual via tree-sitter, o que o torna trivialmente contornável. O autor demonstra que comandos como echo 'git clean -fdx .' | bash, env git status, python3 -c 'import subprocess...' e até echo base64 | base64 -d | bash passam pelo filtro que deveria bloquear git. Permissões persistidas por prefixo de comando criam vetores de ataque: aprovar echo uma vez permite echo 1 > /sys/class/gpio/gpio21/value. A validação de caminhos ignora redirections (que são siblings do command node no AST) e usa uma lista fixa de comandos que acessam arquivos, deixando python3, cargo e outros livres. Uma CVE documentou um servidor HTTP exposto por padrão com CORS permissivo e endpoints POST para execução arbitrária de shell e GET para leitura arbitrária de arquivos - qualquer site visitado poderia obter acesso total ao sistema.

Crítica ao argumento "use Docker"

O autor rejeita a resposta padrão de sandboxing via Docker, argumentando que ele cria um god-service rodando como root, fura firewalls ufw deliberadamente, e não resolve o problema fundamental: um shell local conectado à internet dentro do container não está protegendo nada. A solução correta seria usar mecanismos nativos do sistema operacional como Landlock, Seatbelt ou Restricted Tokens, além de bloquear executáveis específicos e tornar .git read-only.

Reflexão sobre LLMs locais

O autor vê valor em LLMs locais para tarefas orientadas a busca (encontrar bugs, rastrear call chains), mas considera a geração de código um beco sem saída. Modelos locais evitam o "uncanny valley" de parecerem inteligentes antes de fazer algo estúpido, e têm menos capacidade de reproduzir o training set verbatim. A conclusão geral é que o ecossistema de software ao redor de LLMs está "completamente podre" e que engenharia de sistemas real precisa ser feita para transformá-los em ferramentas seguras.