Claude Code Auto Mode e Channels: desenvolva código de qualquer lugar

Imagine que você está no trem. Seu notebook em casa está roendo um refactor de 30 minutos. O celular vibra: o Telegram mostra um resumo do seu próprio bot do Claude Code. Os testes passaram, aqui está o que mudou, aqui está o que quebrou. Você digita a próxima instrução, bloqueia o celular e volta à leitura.

Duas funcionalidades do Claude Code fazem esse ciclo funcionar. O Auto Mode remove os pedidos de aprovação que travariam a sessão. Os Channels encaminham mensagens do Telegram, Discord ou iMessage para a sessão ao vivo como se você mesmo tivesse digitado.

Este tutorial mostra como configurar ambos do zero e rodar um loop de escrever-testar-depurar pelo celular.

Se você é novo nos LLMs da Anthropic, recomendo fazer antes nosso curso Introduction to Claude Models.

Pré-requisitos

Para acompanhar este tutorial, você vai precisar de:

• Claude Code v2.1.83 ou superior (Auto Mode requer v2.1.83, Channels precisam da v2.1.80)
• Bun runtime instalado (todo plugin de Channels precisa dele; Node e Deno não funcionam)
• Um plano Claude nos tiers Max, Team ou Enterprise, ou acesso via API. O Auto Mode não está disponível no Pro; não há add-on que o habilite (nem via uso extra)
• Uma conta do Telegram no seu celular
• Python 3.10 ou superior na máquina host
• Uma máquina que possa ficar acordada enquanto você estiver fora (tampa do notebook aberta, desktop ligado ou um servidor)

O que é o Auto Mode do Claude Code (e por que combiná-lo com Channels)?

Claude Code pede confirmação antes de fazer qualquer coisa que saia do projeto. Os próprios dados da Anthropic mostram que os usuários aprovam 93% desses prompts. Nesse ritmo, os prompts adicionam atrito sem trazer mais segurança.

O Auto Mode substitui esse padrão por um classificador. Cada chamada de ferramenta vai para um modelo Claude separado (Sonnet 4.6) que revisa a ação e a permite ou bloqueia. Execuções longas e sem supervisão deixam de pausar a cada trinta segundos para pedir aprovação.

O classificador roda em um modelo diferente do que escreve o código. Um modelo principal comprometido ou mal direcionado não consegue induzi-lo a aprovar uma chamada ruim. Uma sonda separada examina saídas de ferramentas (conteúdo de arquivos, buscas na web, stdout do shell) para identificar tentativas de prompt injection antes que cheguem ao contexto do Claude.

Nem toda chamada de ferramenta passa pelo classificador. Leituras, buscas de texto, navegação de código e edições em arquivos dentro do diretório do projeto rodam por um caminho rápido, sem revisão. Comandos de shell, buscas na web, qualquer coisa que toque arquivos fora do projeto e qualquer spawn de subagente vão para o classificador.

A Anthropic publicou os números no anúncio do Auto Mode. Em 10.000 chamadas reais de ferramentas, o pipeline gerou taxa de 0,4% de falso positivo. Em 52 ações excessivamente ousadas, a taxa de falso negativo foi de 17%. Trocar --dangerously-skip-permissions pelo Auto Mode é ganho certo. Trocar revisão humana cuidadosa não é: o classificador deixa passar uma em cada seis.

Quando o classificador bloqueia uma chamada, o Claude recebe a negativa como resultado da ferramenta. Espera-se que o Claude encontre um caminho mais seguro, não que contorne o bloqueio. Após três bloqueios consecutivos ou vinte no total, o Auto Mode devolve o controle para você. Execuções headless com claude -p encerram em vez disso.

Auto Mode vs bypassPermissions

Comecei a usar o Auto Mode esperando um bypassPermissions mais esperto. Minha crítica ao bypass era permitir tudo: ler arquivos .env, editar configs e por aí vai.

O Auto Mode corrige isso. Operações em arquivos sensíveis e remoções explícitas são negadas por padrão. A exceção é nomear o arquivo no prompt, permitindo que o classificador autorize a edição. Melhor que o bypass, que não tinha essa checagem.

O que me surpreendeu no Auto Mode é que ele é um modo de decisão, não só de permissão. Eu costumava encadear várias skills do Claude Code em sequência, um pipeline para implementar ou depurar uma feature. Com bypassPermissions, o Claude parava entre etapas e pedia permissão para continuar.

Eu curtia esse padrão: a pausa era onde eu revisava o trabalho ou dizia para o Claude seguir. No Auto Mode, o Claude decide sozinho se tem contexto suficiente para ir para a próxima etapa. Os checkpoints de revisão em que eu confiava somem. Você vai curtir as execuções mais rápidas ou sentir falta das pausas com humano no loop.

A outra surpresa foi na direção oposta. Com bypassPermissions, quando eu pedia para o Claude editar sua própria config ou skills, ele recusava. Com ou sem bypass, ele me perguntava. No Auto Mode, o Claude tem mais liberdade aí: arquivos de skill, configurações em .claude/ e a própria configuração dele podem ser editados sem pedir. Útil para skills autossustentáveis, mas um risco se você espera que o Claude não mexa na própria config.

Auto Mode vs outros modos de permissão

Quatro modos vêm com o Claude Code, e eles ficam num espectro entre "aprovar tudo" e "não aprovar nada". Abaixo vai a versão curta. A versão completa está na documentação oficial.

Minha recomendação: use default para repositórios sensíveis em que toda escrita precisa de um segundo olhar, auto para seus próprios projetos e bypassPermissions só dentro de um container descartável, com o estrago bem contido.

Como os Channels entram na história

Os channels do Claude Code são servidores MCP que enviam eventos para sua sessão em execução. Vamos usar o plugin do Telegram; os plugins de Discord e iMessage funcionam do mesmo jeito. Você envia DM para o bot, o plugin encaminha a mensagem para a sessão e o Claude trabalha nos seus arquivos locais. A resposta volta pelo bot quando a vez termina.

O Claude só te envia mensagem no fim da vez. Não há streaming no meio do turno, nem preview ao vivo do que ele está fazendo no host. Tudo que o Claude executar durante a vez, executou. Você fica sabendo quando o resumo chega. É por isso que o modo de permissão pesa mais via channel do que no terminal.

Os Channels podem encaminhar prompts de permissão para o celular nos modos default ou acceptEdits. Você responde yes ou no pelo Telegram. Para poucos prompts, tudo bem. Em uma sessão real de build-test-debug, vêm dezenas — e tocar em cada um cansa rápido.

O outro extremo é pior. --dangerously-skip-permissions remove os prompts, mas por channel você perde a visualização ao vivo das chamadas de ferramenta do terminal. Nada te avisa que um comando arriscado acabou de rodar. No terminal, o bypass pelo menos permite ver o stream e apertar Esc. No Telegram, você digita um prompt e só descobre o que aconteceu no fim da vez.

O Auto Mode fica no meio do caminho. Nada de spam de prompts. O classificador bloqueia sozinho os movimentos claramente perigosos. A mensagem de fim de vez traz um relato do que rodou. Para trabalho remoto, é o equilíbrio que funciona.

O projeto de demonstração

Eu fiz um demo pequeno chamado libcache. É um CLI em Python que busca metadados de livros na API do OpenLibrary e guarda em cache as respostas em ~/.cache/libcache/.

A stack é propositalmente simples: uv gerencia dependências, typer cuida do CLI, httpx faz as requisições HTTP e pytest roda os testes.

Três pontos sobre o libcache importam.

1. É multi-arquivo, então um build do zero no modo default empilharia uma dúzia de prompts de permissão.

2. Tem uma fronteira HTTP, dando ao classificador uma decisão real a tomar.

3. Termina rápido o bastante para o scaffolding inteiro caber em um único turno do Telegram.

Configurando o Auto Mode e os Channels do Telegram

Três coisas, nesta ordem: máquina host acordada, plugin pareado, Auto Mode ativo. Se qualquer uma falhar, o resto não funciona.

Preparando a máquina host

O Claude Code é um processo local. Quando a máquina dorme, o processo para de receber eventos. O plugin do Telegram não tem onde entregar suas mensagens. Os eventos só chegam enquanto a sessão está aberta.

No macOS, abra um terminal separado e rode:

caffeinate -d

A flag -d evita que a tela durma. Em Linux, você pode mascarar os targets de sleep:

sudo systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target

Isso é reversível com unmask.

Para algo que dure mais que uma tarde, rode a sessão dentro do tmux. Ele mantém o shell vivo com janelas fechadas e conexões SSH caídas. Inicie uma nova sessão:

tmux new -s claude

Inicie o Claude dentro dela, desacople com Ctrl+B, depois D, e reconecte mais tarde:

tmux attach -t claude

Mais uma coisa antes de iniciar. Qualquer CLI que o Claude possa chamar via Telegram precisa já estar autenticada na host. Logins interativos não rodam pelo celular. Confira o gh, o GitHub CLI que vamos usar hoje:

gh auth status

Se não estiver autenticado, rode gh auth login e conclua o fluxo no navegador. Faça o mesmo com qualquer outro CLI que você queira que o Claude use (aws, gcloud, docker, registries de pacotes) para seus outros projetos.

Instalando e configurando o plugin do Telegram

Instale o Bun se ainda não instalou. No macOS ou Linux:

curl -fsSL https://bun.sh/install | bash

No Windows:

powershell -c "irm bun.sh/install.ps1 | iex"

Confirme a instalação:

bun --version

Depois, crie o bot do Telegram.

Abra o BotFather no Telegram, envie /newbot, escolha um display name e um username terminando em bot (algo como libcache_dev_bot). Copie o token que o BotFather enviar.

De volta à sessão do Claude Code, instale o plugin:

/plugin install telegram@claude-plugins-official

Se o Claude Code disser que o marketplace não tem, adicione manualmente e tente de novo:

/plugin marketplace add anthropics/claude-plugins-official

Após instalar, recarregue os plugins para os tools do Telegram aparecerem:

/reload-plugins

Configure o bot com o token do BotFather:

/telegram:configure <your_bot_token_here>

O token é gravado em ~/.claude/channels/telegram/.env.

Depois do /telegram:configure, saia completamente do Claude Code (pressione Ctrl+D ou digite /exit) e reinicie. O /reload-plugins nem sempre mostra o código de pareamento no primeiro DM.

Reinicie a sessão, abra o bot no Telegram e envie /start. O bot responde com um código de pareamento de 6 caracteres.

No Claude Code, faça o pareamento com o código:

/telegram:access pair <code>

O pareamento é simétrico. Os dois lados precisam concordar para a sessão aceitar mensagens.

Último passo. Trave o bot só para sua conta:

/telegram:access policy allowlist

Quem não estiver no allowlist e mandar DM para o bot será ignorado silenciosamente, sem receber código de pareamento.

Iniciando com Auto Mode e Channels ativos

No diretório do projeto, inicie o Claude com as duas flags:

claude --channels plugin:telegram@claude-plugins-official --permission-mode auto

Uma sessão existente pode trocar para Auto Mode no meio do fluxo: pressione Shift+Tab repetidamente até a barra de status mostrar auto. Para tornar o Auto Mode o padrão em todo lançamento, adicione em ~/.claude/settings.json:

{ "permissions": { "defaultMode": "auto" } }

Ao entrar no Auto Mode, o Claude Code remove regras amplas de allow do settings.json. Permissões genéricas como Bash(*), interpretadores com wildcard tipo Bash(python*) e allows gerais de Agent são descartados na entrada e restaurados na saída. Regras estreitas como Bash(pytest) permanecem.

Verifique o setup. Mande qualquer coisa por DM para o bot e veja se recebe resposta. Depois, peça ao Claude para criar um arquivo pequeno no projeto e veja ele surgir sem prompt. Se ambos funcionarem, está tudo pronto.

Auto Mode e Channels do Claude Code em ação

Vamos ver como dar o pontapé pelo Telegram na prática.

Um prompt, muitas chamadas de ferramenta, zero aprovações

Envie um prompt inicial pelo Telegram. O que importa é o tipo de tarefa: algo que empilharia uma dúzia de aprovações no modo default. Para o libcache, o prompt foi mais ou menos:

Create a Python CLI that fetches book metadata from OpenLibrary and caches it to disk, use uv for deps, typer for the CLI, httpx for requests, pytest for tests, scaffold the directory and add a README, and when you're done, summarize what you built in under 80 words.

O “summarize in under 80 words” no fim é um hábito específico de channel. As respostas chegam no celular, e celular é ruim para ler saídas longas.

O plugin envia a mensagem do celular para a sessão em execução no host. Ela aparece como um banner ← telegram · <sender>: ... no terminal.

Escritas em arquivos dentro do projeto seguem o caminho rápido e ignoram o classificador. Instalação de dependências, a primeira execução do pytest e o git init final passam pelo classificador e são permitidos por padrão. Nada pausa e o turno roda de ponta a ponta em uma passada.

No celular, o resumo é o único retorno durante o turno.

Prompts longos são chatos de digitar no celular. Ditado por voz resolve boa parte e prompts curtos e declarativos funcionam bem. "Scaffold libcache, OpenLibrary + cache em disco, menos de 80 palavras" já basta.

O loop de iteração: pedir, rodar, responder, repetir

Cada follow-up roda o mesmo ciclo. Uma mensagem do Telegram, uma vez de trabalho, um resumo de volta. O resumo é o relato do Claude, não o estado real. Peça para rodar os testes e colar a saída literal:

uv run pytest -v

Peça para dar cat em um arquivo específico. Peça tamanhos de arquivo, contagem de linhas ou o histórico recente de commits:

git log --oneline

O Auto Mode roda chamadas de verificação pelos mesmos caminhos rápidos do resto. O custo de perguntar é baixo. O resultado é uma afirmação que você confere da tela bloqueada, sem ir até o notebook.

Mais uma vez para provar que o loop alcança sistemas externos de verdade. Pelo celular:

push libcache to a new public GitHub repo called libcache, clean commit, decent message, send me the URL when it's up.

O Claude usa o CLI gh autenticado antes e responde com a URL do repositório.

Quando o Auto Mode funciona, o loop parece silencioso. A próxima seção mostra o que acontece quando não.

Quando o Auto Mode faz você parar

O Auto Mode te interrompe de duas formas.

O classificador bloqueia com força um pequeno conjunto de padrões:

• pipes curl | bash

• Force-push para a main

• Exclusões em massa em storage na nuvem.

Mais suave e mais comum, o próprio Claude pausa em ações que reconhece como irreversíveis. Ambas aparecem do mesmo jeito no celular: sem banner vermelho, sem modal, só texto normal. O Claude nomeia a ação, lista os comandos e pede uma frase de confirmação específica antes de continuar.

Um pedido destrutivo como "delete o projeto, remova também o repo no GitHub" dispara a pausa de irreversibilidade. A resposta detalha os comandos e oferece alternativas mais seguras: arquivar, só local ou só remoto. Ele espera por uma frase escolhida pelo Claude, não um simples sim/não.

A mesma captura mostra um segundo efeito. No meio da remoção, o Claude esbarrou em um escopo ausente no CLI gh (o token não tinha delete_repo). Em vez de deixar o trabalho pela metade, o Claude pausou e pediu para eu rodar um comando interativo no terminal:

gh auth refresh -h github.com -s delete_repo

O Auto Mode não consegue tocar fluxos de autenticação via navegador, e o Claude não tentou contornar o escopo faltante.

Histórico da sessão não é consentimento implícito. Mesmo para um repo que o próprio Claude criou quinze minutos antes, na mesma sessão, a pausa ainda dispara na exclusão. O mesmo limite de 3 consecutivos / 20 no total se aplica. Interrupções empilhadas acabam devolvendo o controle ao humano.

Dois bugs conhecidos para ficar de olho. Às vezes as mensagens não entregam quando o Claude Code está ocioso no prompt do REPL (issue #48404). Depois de uma resposta, o plugin às vezes para de encaminhar novas mensagens até ser cutucado (issue #36477). Workarounds: manter um turno em andamento ou reiniciar a sessão. Ainda sem correção.

Ajustando as regras de segurança do Auto Mode

Para a maior parte do trabalho no seu próprio código, os padrões do Auto Mode bastam. Quando quiser reforçar paths específicos ou aliviar outros, comece lendo o que a Anthropic definiu para você:

claude auto-mode defaults

Isso imprime as regras embutidas de allow e block em JSON. A estrutura é feita para ser estendida, não substituída: edite a base, não reescreva do zero. Toda regra removida força o classificador a decidir — e cada decisão abre chance de falso negativo.

Adicione regras específicas do projeto no settings.json na chave permissions. Allows estreitos seguem para o Auto Mode sem mudanças. Os amplos são descartados na entrada. Uma regra como Bash(pytest) ou Bash(gh pr create *) é específica o suficiente para o classificador confiar no seu julgamento. Na prática: um allow estreito por ferramenta que o projeto realmente usa, sem wildcards.

Se seu workflow dependia de prompts de permissão como gates de revisão entre estágios do pipeline, traga esses checkpoints de volta explicitamente. Adicione regras ask para os padrões de ferramenta ou paths onde você quer que o Claude pare. Ou mova esse workflow para acceptEdits em vez de auto para manter o checkpoint de prompt em tudo, exceto edições dentro do projeto.

Um recurso pouco usado: o classificador trata limites declarados na conversa como sinais de bloqueio. Diga ao Claude: "não faça push até eu revisar", e ele bloqueia ações correspondentes mesmo quando as regras padrão permitiriam. É uma alternativa simples a escrever uma regra formal só para aquela sessão.

Para ver a configuração efetiva após seu settings.json mesclar com os padrões:

claude auto-mode config

Admins Enterprise podem desativar o recurso para toda a organização via permissions.disableAutoMode: 'disable' em managed settings.

Conclusão

Auto Mode mais Channels transforma o Claude Code de uma ferramenta presa à mesa em um parceiro assíncrono que você comanda de qualquer lugar. O classificador decide quais chamadas de ferramenta passam. O Claude decide quando uma ação é séria o suficiente para pausar. Você decide os prompts, o escopo e as regras. O terminal é só mais um lugar de onde você pode trabalhar, não o único.

Para se aprofundar, recomendo nossos guias sobre Claude Code Remote Control, Claude Code Plugins e Claude Code Best Practices.