ACP — ChatCLI dentro da sua IDE

​

Início rápido

# 1. Garanta que o chatcli funciona standalone primeiro
chatcli --version

# 2. Suba o servidor ACP (a IDE faz isso por você depois de configurada)
chatcli acp

​

IDEs JetBrains (IntelliJ IDEA, GoLand, WebStorm, …)

{
  "default_mcp_settings": {
    "use_custom_mcp": true,
    "use_idea_mcp": false
  },
  "agent_servers": {
    "ChatCLI": {
      "command": "/usr/local/bin/chatcli",
      "args": ["acp"],
      "env": {
        "LLM_PROVIDER": "CLAUDEAI",
        "LLM_MODEL": "claude-sonnet-4-6"
      }
    }
  }
}

​

Zed

{
  "agent_servers": {
    "ChatCLI": {
      "command": "/usr/local/bin/chatcli",
      "args": ["acp"],
      "env": { "LLM_PROVIDER": "CLAUDEAI" }
    }
  }
}

​

Modos de sessão

/coder            → muda esta sessão para o modo coder
/coder conserte os testes quebrados   → muda E já executa a tarefa
/chat             → volta para conversa pura

​

Slash commands na IDE

​

Dialogs de permissão

• As regras ask da sua política de segurança abrem o dialog nativo da IDE com o vocabulário completo do terminal: Allow / Always allow / Reject / Always reject. As opções always persistem uma regra no coder_policy.json — exatamente o que apertar a ou d faz no prompt do terminal — então a próxima ocorrência nem precisa de dialog.
• Quando o coder quer executar um comando classificado como perigoso (deletes recursivos, force push, escalação de privilégio…), o dialog oferece só Allow once / Reject once: comandos exec nunca ganham um always geral, espelhando o prompt interativo que esconde essas opções para eles de propósito.
• Qualquer coisa que não seja um Allow explícito — reject, dialog fechado, crash do cliente, timeout — nega a ação. O agente vê a recusa in-band e replaneja; um Always reject também registra uma regra deny permanente.
• O mesmo gate cobre blocos shell propostos pelo agente no modo agent.

​

Seus servidores MCP funcionam aqui também

• Peça ao agente algo que precise de uma tool MCP (“veja as issues abertas do Jira”, “consulte o banco de staging”) e ele chama a tool do servidor conectado autonomamente. Na IDE, a chamada renderiza como uma tool call estruturada nativa igual a qualquer built-in.
• Hot reload — editar o mcp_servers.json reconecta servidores ao vivo; sem reiniciar IDE nem agente. /mcp na caixa de prompt mostra status de conexão e tools.
• Servidores remotos com OAuth precisam ser autorizados antes (rode @mcp-login no terminal uma vez; os tokens persistem no keychain).

​

Por baixo do capô (para integradores)

​

Notas operacionais

• Um run por vez — runs de agent/coder serializam no processo (compartilham o estado do engine). O prompt de uma segunda sessão espera o run atual terminar; um segundo prompt na mesma sessão é rejeitado enquanto há um em voo — e uma sessão enfileirada que você cancela desiste do lugar imediatamente, em vez de ficar presa atrás do run ativo.
• Parks e monitores ficam no turno — quando o modelo usa @park (ex.: “verifique o gate do PR a cada 30s”), o turno fica aberto e cada ciclo de monitoração streama na IDE na mesma request; apertar Stop cancela o monitor por completo (job do scheduler + snapshot). Esperas síncronas do @scheduler emitem uma linha de heartbeat ⏳ a cada 30s. Veja Agent park & resume.
• Dialogs de permissão são limitados e honestos — cada session/request_permission espera até CHATCLI_MCP_PERMISSION_TIMEOUT (padrão 600s; off = teto de 24h). Um timeout ou uma falha no round-trip do dialog bloqueia a ação fail-safe, mas é reportado ao modelo como sem resposta/falhou, nunca como negação do usuário.
• Ambiente — o processo ACP é um boot normal do ChatCLI: arquivo de ambiente, logins OAuth no keychain, catálogos de provider, config de cliente MCP e skills resolvem como no terminal. Uma ressalva importante: a IDE não executa o seu shell profile, então CHATCLI_DOTENV e qualquer export do .zshrc/.bashrc não chegam no processo do agente, e o diretório de trabalho dele é o projeto. Por isso o ChatCLI cai para ~/.chatcli/.env e depois ~/.env quando não há ./.env — mantenha seu arquivo em um desses e a IDE concorda com o terminal. O que a IDE precisar fixar explicitamente vai no bloco env. O /config na caixa de prompt mostra o arquivo em efeito, a origem dele e o profile AWS efetivo.
• Configuração por projeto — o projeto aberto na IDE (o cwd do session/new) contribui com o .env dele por cima, somente preenchendo: pode adicionar variáveis que você não definiu, nunca sobrescreve uma já em efeito, e só o primeiro projeto anunciado se aplica. Diretório de projeto é entrada não confiável, então CHATCLI_PROJECT_ENV=safe (padrão) recusa variáveis de credencial e endpoint vindas dele; all aceita tudo e off desliga.
• Sessões são por sessão e restauráveis — cada sessão da IDE mantém seu próprio histórico de conversa. session/load (capability loadSession: true) traz de volta um session id anterior: o estado vivo se o servidor ainda está rodando, ou o espelho de autosave mcp-<id> após um restart, com a conversa replayada na IDE. Para continuidade durável entre superfícies, vincule a uma sessão nomeada com /session attach <nome> — veja Continuidade cross-surface.
• Logs — stdout é o protocolo; diagnóstico vai para o arquivo de log padrão do ChatCLI. Coloque LOG_LEVEL=debug no bloco env do agente ao investigar.

​

Troubleshooting

​

Veja também

• MCP Server — o subcomando irmão: a superfície completa do ChatCLI como tools MCP
• Coder Plugin — o que o engine do coder consegue fazer
• Coder Security — a classificação de comandos perigosos por trás dos dialogs de permissão
• Referência de Comandos — a superfície completa de slash commands
• Variáveis de Ambiente — knobs de provider/modelo/segurança