Desenvolvedor transferiu a autenticacao do Claude Code para um VDS e manteve os projetos no Mac

Em outubro, muitos usuarios do Claude na Russia e em paises vizinhos voltaram a ter suas contas suspensas. O autor da analise publicada no Habr perdeu sua assinatura Max um dia antes da cobranca e, como ele razoavelmente presumiu, o suporte nao teria resolvido nada. Ele comprou uma nova assinatura e montou uma configuracao na qual os projetos permanecem no Mac, enquanto a autenticacao da Anthropic e a saida de rede ficam em um servidor Linux. Trata-se de um experimento pessoal, e o proprio autor ressalta que ele nao deve ser considerado um guia universal.

Por que Remote SSH e um proxy simples nao foram suficientes

A primeira ideia era a mais obvia: instalar o Claude Code no VDS e conectar-se por meio do VS Code Remote SSH. Isso funciona, mas os projetos do Mac nao aparecem automaticamente no servidor. E possivel clonar os repositorios e configurar a sincronizacao, mas o autor nao queria manter certos arquivos em uma maquina de terceiros. O requisito ficou assim: o Claude Code deveria ler e alterar arquivos no Mac, as solicitacoes ao modelo deveriam sair pelo Linux e a autenticacao deveria permanecer no Linux.

A segunda ideia, usar um proxy HTTP no servidor, tambem nao funcionou. O proxy muda a rota do trafego, mas nao fornece ao cliente no Mac a autenticacao de outra maquina. Por isso, foram necessarios dois componentes diferentes. O CLIProxyAPI e um gateway que recebe a solicitacao do Claude Code local e acessa a Anthropic usando as credenciais do servidor. O Tinyproxy encaminha o restante do trafego do cliente: pesquisas na web, MCP e outras requisicoes que, de outro modo, sairiam do endereco IP residencial.

Como a configuracao funciona

No Mac, o settings.json define ANTHROPIC_BASE_URL como uma porta local e HTTP_PROXY e HTTPS_PROXY como uma segunda porta, enquanto o apiKeyHelper fornece a chave do gateway. As duas portas sao encaminhadas por um unico tunel SSH ate o servidor, onde o gateway e o proxy escutam apenas em 127.0.0.1. Um LaunchAgent inicia e reinicia o tunel. O proprio modelo, naturalmente, calcula a resposta na nuvem da Anthropic. O gateway, o token e a saida de rede permanecem no servidor; os arquivos, o agente e a execucao das ferramentas locais permanecem no Mac. Apenas os trechos de arquivos selecionados pelo agente e os resultados dos comandos locais sao enviados ao modelo.

O autor realizou muitas verificacoes porque encontrou armadilhas em todas as etapas. Ele conferiu o IP externo por meio do proxy, inspecionou o binario da extensao do VS Code e confirmou que as operacoes com arquivos eram executadas no Mac. Tambem iniciou o cliente separadamente enquanto o gateway e o proxy estavam indisponiveis: nenhuma resposta chegou por uma rota alternativa, apenas um erro de conexao.

Onde tudo quebrou

O primeiro problema foi o systemd. A importacao da autenticacao em ExecStartPre nao conseguia acessar a variavel de ambiente necessaria, e o servico falhava antes de o gateway iniciar. O autor executou a importacao separadamente, e o servico passou a ler um arquivo auth ja preparado. O token precisa ser atualizado manualmente.

O segundo problema foi NO_PROXY. Sem uma excecao para loopback, a solicitacao ao gateway local passava primeiro pelo Tinyproxy, e nada funcionava.

O terceiro problema, e o mais instrutivo, foi o catalogo de modelos. O cliente solicitou o modelo auxiliar claude-haiku-5-5, que nao constava no catalogo do CLIProxyAPI 8.0.20, e recebeu o erro unknown provider for model. A solucao foi adicionar ao catalogo um registro para o modelo. O autor conclui que as versoes do cliente e do gateway devem ser fixadas e atualizadas de forma deliberada.

Ha ainda outra limitacao: depois que o computador entra em repouso ou ocorre uma interrupcao de rede, o tunel volta a se conectar, mas uma solicitacao ao modelo que ja tenha sido interrompida nao e retomada.

O que tirar disso e o que deve ser lembrado

O padrao e util mesmo fora do contexto de bloqueios. Quando e necessario manter as credenciais e a saida de rede em uma maquina, mas os arquivos e as ferramentas em outra, funciona a arquitetura de um agente local, um gateway atras de um tunel SSH e um proxy separado. Ela tambem mostra que um gateway de API e um proxy de rede resolvem problemas diferentes e nao substituem um ao outro.

No entanto, a abordagem tem ressalvas importantes. O proprio autor reconhece que ter um VDS nao substitui os requisitos da Anthropic sobre a localizacao real do usuario e que fazer coincidir os paises do cartao, do SIM e do servidor nao garante nada. Ele tambem compartilha a assinatura com um amigo, o que cria outra area de risco: servicos e portas compartilhados no mesmo VDS, com varios usuarios tendo acesso root.

O setup-token fica armazenado no servidor, o que transforma o servidor em um ponto critico. Contornar restricoes regionais e compartilhar uma assinatura podem contrariar os termos do servico, portanto a conta pode ser perdida novamente. Para equipes, e melhor usar essa arquitetura quando houver acesso legitimo e necessidade de uma saida centralizada, e nao como forma de contornar as regras do provedor.

O artigo no Habr termina no meio da analise dos detalhes do trabalho colaborativo, portanto nao oferece uma visao completa do acesso compartilhado.