Quais CLIs o OpenDesign aceita? Claude Code, Codex, Cursor, OpenCode e o caminho BYOK

A dúvida que trava a adoção do OpenDesign não é preço, nem instalação, é uma pergunta bem seca: ele funciona com a CLI que eu já uso?

Faz sentido, né? O projeto não se vende como mais um agente pra tu instalar do zero e configurar de novo

Ele se apresenta como uma camada que roda EM CIMA dos agentes de linha de comando que já estão na tua máquina, aqueles que tu já abre todo dia e quanto cada CLI custa por mês tu já sabe de cabeça

E a resposta boa dessa pergunta não está em listinha de terceiro, está declarada no README oficial e, principalmente, no registro do daemon, que é onde a lista de agentes suportados vive de verdade

Bora abrir isso?

Formação Recomendada

Formação Vibe Coding

Do Prompt ao Produto: Crie Software Real com IA

• 474 aulas
• 20 projetos
• 39h 27min

Conhecer formação

O que é o OpenDesign e onde essa lista vive

O OpenDesign é um projeto open source hospedado no GitHub, sob a organização nexu-io, no repositório nexu-io/open-design

Detalhe bobo que confunde na busca: a org aparece no GitHub como "OpenDesign", mas o caminho é nexu-io/open-design

A distribuição é de app desktop local-first: tem build pra macOS e pra Windows, AppImage pro Linux, e os assets saem pelo GitHub Releases

Quantas CLIs, afinal?

O README declara assim: o OpenDesign roda em 26 executáveis de CLI locais distintos, ou em qualquer endpoint compatível com OpenAI via BYOK

Aí tem um detalhe fino que quase todo mundo erra ao repetir esse número por aí

O registro base tem 27 definições de runtime, apoiadas em 26 executáveis distintos, porque a definição byok-opencode compartilha o mesmo executável do OpenCode

Ou seja: 27 e 26 não se contradizem, são coisas diferentes. Definição de runtime × binário que roda na tua máquina

A descrição do repositório resume tudo de um jeito bem mais comercial, jogando Claude Code, Codex, Cursor, DeepSeek Harness e OpenCode como cartão de visita e misturando CLI local com BYOK na mesma frase

Por isso não vale contar CLI pela descrição: o README e o registro é que dizem o que é executável local e o que é endpoint

Onde está a fonte de verdade:

Aqui é o pulo do gato pra quem quer conferir em vez de acreditar

• a lista viva e autoritativa de agentes suportados fica na constante BASE_AGENT_DEFS, em apps/daemon/src/runtimes/registry.ts
• as definições por runtime, uma a uma, ficam em apps/daemon/src/runtimes/defs/
• o contrato de adaptador de agente (o que uma CLI precisa cumprir pra entrar) está documentado em docs/agent-adapters.md

Guarda isso: qualquer número citado sobre CLIs suportadas envelhece a cada release, inclusive o que tu acabou de ler

O registro não envelhece, ele É a lista 🙂

CLIs suportadas: quem entra como runtime e quem entra como slug de MCP

Agora a parte onde mora a confusão

Ser citada no README como CLI suportada e ter caminho de uma linha pro servidor MCP são DUAS coisas diferentes

As CLIs nomeadas explicitamente no README do projeto incluem DeepSeek Harness (dsh), Claude Code, OpenClaw, Codex, Cursor, OpenCode, Qwen, Copilot, Amp, Hermes, Kimi e Antigravity

Já o instalador de MCP aceita hoje os slugs da constante AGENT_SLUGS: claude, codex, cursor, copilot, openclaw, antigravity, pi, vibe, hermes, cline, kimi, trae e opencode

Cruzando as duas listas:

Repara que a tabela tem os dois sentidos de "falta"

Tem CLI citada no README que não tem slug de MCP, e tem slug de MCP de CLI que o README não cita nominalmente

O caso do Kiro é o mais claro: ele não está em AGENT_SLUGS, então não existe caminho de uma linha pra instalar o servidor MCP do OpenDesign nele, e já tem issue aberta pedindo o suporte

Essa mesma pergunta de compatibilidade entre Cursor, Codex e Claude Code aparece em toda ferramenta nova que se pluga em agente, então vale ter o hábito de checar a lista na fonte

Como checar se a sua CLI está coberta

Passo a passo curto, tudo verificável no repositório

1. Abra o registro e ache a sua CLI. Vá em apps/daemon/src/runtimes/registry.ts e procure a constante BASE_AGENT_DEFS. É ali que as definições são registradas

2. Confira a definição do seu agente. Cada runtime tem seu arquivo em apps/daemon/src/runtimes/defs/. Se tem arquivo e entrada no registro, tá coberto

3. Entenda COMO ele te acha antes de sair debugando. A detecção varre o PATH do usuário e diretórios comuns de toolchain, e a checagem sonda o executável configurado, de fallback ou empacotado que a execução realmente vai disparar

O erro comum deste passo: achar que rodar which resolve a dúvida. Não resolve, porque o primeiro shim visível no PATH pode não ser o binário que o OpenDesign vai spawnar de fato

4. Plugue o OpenDesign dentro do agente. Se a sua CLI tem slug, é uma linha só:

od mcp install <agent>

O erro comum deste passo: chutar o slug. Ele precisa ser um dos aceitos em AGENT_SLUGS (claude, codex, cursor, copilot, openclaw, antigravity, pi, vibe, hermes, cline, kimi, trae, opencode)

5. Valide o acesso ao projeto. Depois do install, o agente passa a poder rodar os comandos do OpenDesign pra listar e ler o projeto:

od project list --json
od files list <project-id> --json
od files read <project-id> <relative-path>
od plugin list --json
od skills list --json

Se od project list --json já devolve o teu projeto, o caminho tá de pé. Se não devolve, o problema é acesso, não é a CLI

Não achou sua CLI na lista? Os caminhos que sobram

Três cenários, escolhe o teu

1. A sua CLI está no registro:

Sorte tua, é o fluxo de sempre

A CLI já instalada é detectada, o OpenDesign dispara o executável real e tu só decide se quer também plugar o MCP dentro do agente pelo od mcp install

2. A sua CLI não está coberta e você não quer esperar release:

Aqui é onde o projeto ser open source paga a conta

Adicionar uma CLI nova é criar um arquivo em runtimes/defs/<cli>.ts e acrescentar a definição em BASE_AGENT_DEFS, sem mexer no core do daemon

Detecção, launch, invocação e parsing vêm de graça pelo contrato de adaptador

Se tu já mexeu com sistema de plugins antes, é bem aquela sensação: o core não te pergunta quem tu é, ele só lê a definição que tu registrou

O contrato inteiro está em docs/agent-adapters.md, vale ler antes de sair escrevendo

3. Você não tem CLI nenhuma instalada:

Tem saída também, e ela é a mais universal das três

O proxy BYOK do OpenDesign roda o mesmo loop sem disparar processo local, pelos endpoints POST /api/proxy/{anthropic,openai,azure,google,ollama,senseaudio}/stream, com proteção contra SSRF

Na prática tu cola baseUrl, apiKey e model, e pronto

E tem preset pronto pra OpenAI, Atlas Cloud, Anthropic, Azure OpenAI, Google Gemini, Ollama, LM Studio, vLLM ou qualquer endpoint compatível com OpenAI

Ou seja: máquina limpa, sem toolchain de agente, e ainda assim dá pra rodar. Massa 😀

Conclusão

O veredito honesto sobre a compatibilidade do OpenDesign é: a cobertura declarada é ampla, mas ela tem três camadas que não são a mesma coisa

A primeira é a dos runtimes nomeados, 26 executáveis distintos em 27 definições, que é onde entram Claude Code, Codex, Cursor, OpenCode e companhia

A segunda é o BYOK, que funciona como saída universal pra quem não tem CLI local, ou tem uma que ninguém adaptou ainda

E a terceira é o MCP, que é caminho SEPARADO e tem lista menor: se o teu agente não está em AGENT_SLUGS, não existe o caminho de uma linha do od mcp install pra ele, ponto

Então o próximo passo concreto é simples: antes de assumir suporte, abre BASE_AGENT_DEFS no repositório e confere com os próprios olhos

A lista muda a cada release, e é bem mais rápido ler o registro do que descobrir no susto que a tua CLI ficou de fora…

até o próximo post!