Técnica

Claude Code pelo celular, com acesso ao seu segundo cérebro inteiro

18 de ago. de 2026

claude-codesetupmemoriaworkflowcelular

Problema

Eu uso o Claude Code em cima de uma pasta que é o meu segundo cérebro: memória, índice, projetos, áreas, skills, integrações. Quando estou no computador, isso funciona como um assistente que conhece o meu contexto. Quando estou na rua, o que eu tinha até esta semana era o app do Claude com um chat em branco, sem nenhum dos meus arquivos.

O Remote Control resolve metade disso: com uma sessão aberta no terminal, o comando /remote-control deixa você continuar aquela sessão pelo celular. O que ele não resolvia no meu fluxo era o esquecimento. Se eu saía de casa sem ter aberto uma sessão, ou se a sessão fechava por qualquer motivo, não tinha como começar uma nova de longe. E o esquecimento acontece: o dia em que você mais precisa da sessão remota é o dia em que você saiu correndo.

A pergunta que eu me fiz foi: dá pra deixar o computador sempre pronto pra abrir sessão nova pelo celular, sem eu lembrar de nada? Dá, e é mais simples do que parece. A resposta está em tratar o Remote Control como um servidor que fica ligado, em vez de um comando que você digita dentro de uma sessão.

Técnica

A peça central é o comando claude remote-control rodado direto no terminal, na pasta que você quer expor. Diferente do /remote-control de dentro de uma sessão, ele não é uma sessão: é um processo que fica escutando e cria sessões novas sob demanda quando você pede pelo app do celular ou pelo claude.ai/code. Na minha versão (2.1.234), o próprio --help descreve isso: “Remote Control runs as a persistent server that accepts multiple concurrent sessions in the current directory”, com capacidade padrão de 32 sessões.

Isso muda o problema. Deixa de ser “esqueci de abrir a sessão” e vira “esqueci de subir o servidor”. E servidor a gente sobe automaticamente quando o computador liga.

O caminho tem 3 partes: testar o servidor na mão, deixar ele subindo sozinho, e garantir que a máquina fique acordada.

Parte 1: testar na mão (2 minutos)

Abre o terminal, entra na pasta do seu segundo cérebro (ou qualquer pasta que você queira alcançar de longe) e roda:

claude remote-control --name "Segundo Cérebro" --spawn=same-dir

Duas observações antes de rodar. Você precisa ter aberto o claude normal nessa pasta pelo menos uma vez, pra aceitar o aviso de confiança da pasta. E na primeira vez o comando pergunta o modo de criação das sessões; o --spawn=same-dir já responde isso na linha de comando (todas as sessões nascem na mesma pasta, que é o que você quer pra um segundo cérebro).

Se deu certo, aparece algo assim:

·✔︎· Ready · Segundo Cérebro · main
    Capacity: 0/32 · New sessions will be created in the current directory
Code anywhere with the Claude mobile app or https://claude.ai/code?environment=env_...

Deixa esse terminal aberto, pega o celular, abre o app do Claude, vai em Code e cria uma sessão nova. Na hora de escolher onde ela roda, a sua máquina aparece com o nome que você deu. Escolhe ela, escreve o pedido, e a sessão nasce no seu computador, dentro da sua pasta, com tudo que ela tem.

Só isso já resolve o caso de uso. O que falta é não depender de você lembrar de rodar o comando.

No Mac, o jeito nativo de manter um processo vivo é o launchd. Ele sobe o servidor quando você loga e religa se cair. Cria o arquivo ~/Library/LaunchAgents/com.seunome.claude-remote-control.plist com este conteúdo, trocando o caminho da pasta, o caminho do claude (descubra com which claude) e o seu usuário:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>Label</key>
  <string>com.seunome.claude-remote-control</string>
  <key>ProgramArguments</key>
  <array>
    <string>/bin/sh</string>
    <string>-c</string>
    <string>tail -f /dev/null | exec /usr/bin/script -q /dev/null /Users/SEU_USUARIO/.local/bin/claude remote-control --name "Segundo Cérebro" --spawn=same-dir</string>
  </array>
  <key>WorkingDirectory</key>
  <string>/Users/SEU_USUARIO/caminho/para/sua/pasta</string>
  <key>EnvironmentVariables</key>
  <dict>
    <key>USER</key>
    <string>SEU_USUARIO</string>
    <key>HOME</key>
    <string>/Users/SEU_USUARIO</string>
    <key>TERM</key>
    <string>xterm-256color</string>
    <key>PATH</key>
    <string>/Users/SEU_USUARIO/.local/bin:/opt/homebrew/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin</string>
  </dict>
  <key>RunAtLoad</key>
  <true/>
  <key>KeepAlive</key>
  <true/>
  <key>ThrottleInterval</key>
  <integer>30</integer>
  <key>StandardOutPath</key>
  <string>/Users/SEU_USUARIO/.claude/remote-control.log</string>
  <key>StandardErrorPath</key>
  <string>/Users/SEU_USUARIO/.claude/remote-control.error.log</string>
</dict>
</plist>

Depois carrega o serviço:

launchctl bootstrap gui/$(id -u) ~/Library/LaunchAgents/com.seunome.claude-remote-control.plist

E confere, uns 30 segundos depois, se o log mostra o Ready:

tail -5 ~/.claude/remote-control.log

Duas linhas desse arquivo parecem gambiarra e são o que faz funcionar. Eu perdi quase uma hora nelas, então explico:

TERM=xterm-256color nas variáveis de ambiente. O servidor desenha uma interface de terminal, e o launchd não define TERM. Sem essa linha ele sobe e fica mudo: processo vivo, nenhum Ready, nenhuma máquina no app.
tail -f /dev/null | ... script -q /dev/null .... O script dá um pseudo-terminal pro Claude, que ele espera ter. Mas o launchd entrega /dev/null como entrada, o script repassa o fim de arquivo, e o Claude entende como “o usuário fechou”: chega em Ready e sai com código 0 segundos depois, e o KeepAlive fica religando pra sempre. O tail -f /dev/null é uma entrada que nunca fecha.

Se algum dia a máquina sumir do app, o diagnóstico é launchctl print gui/$(id -u)/com.seunome.claude-remote-control (mostra estado, PID e quantas vezes rodou) e o log acima. Pra religar na mão: launchctl kickstart -k gui/$(id -u)/com.seunome.claude-remote-control. Pra recarregar depois de editar o arquivo, é bootout e bootstrap de novo, porque o launchd só relê o plist na carga.

Em Linux o equivalente é uma unit de systemd --user com Restart=always e as mesmas duas precauções (Environment=TERM=xterm-256color e stdin que não feche). Não testei; se você fizer, me conta.

Parte 3: máquina acordada e na internet

O servidor roda no seu computador, então o computador precisa estar ligado, acordado e conectado. No Mac, o caffeinate segura o sono enquanto roda (caffeinate -s numa aba de terminal, ou como outro serviço do launchd), e a tampa pode ficar fechada se ele estiver ligado na tomada e num monitor ou com o sono de tampa desativado. Vale conferir com pmset -g se aparece sleep prevented by caffeinate.

Isso é a condição de contorno de verdade. Notebook que dorme na mochila não atende ninguém.

Como aplicar

Depois de instalado, o uso do dia a dia é:

Abre o app do Claude no celular (ou claude.ai/code no navegador).
Vai em Code, cria uma sessão nova.
Escolhe a sua máquina na lista de ambientes.
Escreve o pedido normal. A sessão roda no seu computador, com os seus arquivos, as suas skills e as suas integrações locais.

Não tem passo no computador. O /remote-control de dentro da sessão continua útil pra continuar pelo celular uma sessão que você já estava usando na mesa; o servidor é pra começar do zero quando você está longe.

Três cuidados que eu adotei e recomendo:

Não troque isso pelo repositório na nuvem. A alternativa óbvia é subir a pasta pro GitHub e usar sessões na nuvem do Claude Code, que também abrem pelo celular. Pra código público, ótimo. Pra um segundo cérebro, não: a pasta costuma ter finanças, saúde, contatos, material de trabalho, e isso não sai da máquina só pra ganhar conveniência. Além disso a sessão na nuvem não enxerga os seus MCPs locais, seus hooks e nem a sincronização de arquivos que você já tem. O servidor local dá o mesmo resultado sem mudar nada da sua arquitetura.
Modo de permissão com juízo. O servidor aceita --permission-mode pras sessões que ele cria. Pelo celular você aprova menos coisa com atenção, então eu prefiro deixar o padrão e responder as permissões, em vez de liberar tudo. Sessão remota com permissão total é a mesma coisa que emprestar o computador.
Uma pasta por servidor. Se você quiser alcançar outra pasta (um repositório de código, por exemplo), é outro claude remote-control em outro serviço, com outro nome. No app eles aparecem separados, e você escolhe onde a sessão nasce.

O ganho, pra mim, foi que o segundo cérebro passou a existir fora da mesa. Ideia no meio da rua, pergunta sobre um projeto na fila do mercado, texto que precisa sair antes de eu chegar em casa: tudo isso agora começa no celular, com o mesmo contexto que eu teria sentado. Talvez o mais interessante seja o quanto isso muda o que eu delego: eu abro a sessão, peço, guardo o celular, e quando chego a tarefa está feita, nos meus arquivos.

Problema

Técnica

Parte 1: testar na mão (2 minutos)

Parte 2: subir sozinho no login (macOS)

Parte 3: máquina acordada e na internet

Como aplicar