OpenCode em um servidor: como fazer um agente de IA trabalhar enquanto você dorme

Uma história conhecida: você iniciou um agente de IA no terminal, ele travou no momento mais interessante, depois você fechou o notebook e a sessão inteira sumiu. Claude Code e Codex são fechados e voltados aos modelos de seus próprios autores. O OpenCode, um harness de código aberto, não tem essa limitação: funciona com qualquer provedor e, principalmente, pode ser hospedado em um servidor.

Por que isso é possível

Por baixo dos panos, o OpenCode usa um esquema cliente-servidor. A TUI conversa com um servidor HTTP local, que publica uma especificação OpenAPI no endpoint /doc. O comando opencode serve sobe esse mesmo servidor sem interface. Por padrão, ele escuta em 127.0.0.1:4096, e o endereço e a porta são alterados com as flags --hostname e --port. Dá para acessá-lo a partir de CI, de cron ou de outro script, e ainda mantê-lo aquecido para não pagar pela partida a frio de MCP e LSP.

Se o servidor estiver acessível além do localhost, defina obrigatoriamente OPENCODE_SERVER_PASSWORD. Será ativado o HTTP basic auth, com o nome de usuário padrão opencode. Só a senha não basta: coloque o servidor atrás de nginx ou Caddy com HTTPS; caso contrário, o basic auth sobre HTTP aberto protege apenas contra varreduras casuais.

Onde isso é útil

O cenário mais simples é CI/CD e revisão de pull requests. Com o aplicativo do GitHub, basta mencionar /opencode ou /oc em um comentário, e o agente inicia em um runner do GitHub Actions, lê o contexto e, se necessário, abre um PR com a correção. Sem o aplicativo, escreve-se no workflow uma etapa com opencode run --standalone: no CI não há uma TUI em execução, então o próprio comando sobe um servidor privado para a tarefa. A saída dos modelos não é determinística, então não convém delegar ao agente avaliações por nota, mas para revisão ele é perfeitamente adequado.

O segundo cenário são as tarefas noturnas. O plugin opencode-scheduler usa launchd no macOS e systemd no Linux, com cron como alternativa. Uma auditoria diária de dependências ou um relatório do git log é agendado e esquecido. O terceiro é um servidor comum para a equipe: plugins de IDE, uma interface web ou uma ponte do Telegram se conectam a um único processo e veem as mesmas sessões.

Systemd ou Docker

Em um VPS limpo, basta uma unit do systemd com o comando opencode serve. A principal armadilha é o PATH. Os serviços do systemd não herdam o PATH do seu shell, por isso não são encontrados nem o próprio OpenCode nem tudo o que o agente chama via bash: git, node, rg, make. Defina Environment=PATH=... e HOME explicitamente.

O Docker oferece isolamento do sistema de arquivos e repetibilidade. Fixe uma versão específica da imagem, monte o workspace em um volume separado e as configurações e sessões em outro. Mas isso é proteção contra um rm acidental, não contra uma fuga deliberada.

Permissões, provedores, segurança

O provedor é conectado via @ai-sdk/openai-compatible: serve qualquer endpoint compatível, do Ollama local a um gateway na nuvem. No exemplo do artigo é usado o BotHub, patrocinador do material. É melhor não guardar a chave de API na configuração, mas adicioná-la por meio de opencode auth login. Para tarefas de serviço, como títulos de sessão, defina um small_model barato.

No servidor não se deve deixar a regra ask: o opencode serve pode esperar horas por uma resposta que nunca virá. Use regras allow pontuais sobre deny, ou a flag --auto, que transforma ask em allow, mas preserva deny.

O mais importante: o SECURITY.md diz claramente que o OpenCode não é um sandbox e que o sistema de permissões é apenas UX. Servidores MCP externos ficam fora do limite de confiança, e um caso recente de MCP malicioso que executava código via OAuth confirmou isso. Outra dor de cabeça é o Bun: ele lê o HTTP_PROXY de forma instável, não entende socks5://, e sem NO_PROXY para localhost o agente pode entrar em loop com as próprias requisições.

Monitoramento e conclusão

Há um health-check em /global/health, logs no journald ou no Docker, e o plugin opencode-otel envia traces para Jaeger, Grafana Tempo, Datadog ou Langfuse. Para CI, é conveniente opencode run --format json. Fique de olho no consumo de tokens: à noite o agente trabalha sem supervisão.

Conclusão prática: subir um agente em um servidor leva uma noite, e o trabalho de verdade começa depois. Isolamento, HTTPS, permissões rígidas e observabilidade são obrigatórios. Ele funciona melhor onde está integrado a um processo: auditorias noturnas, revisão de PR. É melhor não dar a ele acesso à produção: deixe que prepare o PR, e o botão você aperta.