Encerramento do Conductor Cloud: exporte antes de 20 de novembro

Por precaução, conclua e verifique as transferências dos espaços de trabalho do Conductor Cloud antes de 13 de novembro de 2026. Conclua e verifique nesse mesmo prazo as etapas de backup que dependem de acesso ao terminal do Cloud. Baixe e verifique o arquivo separado da conta antes de 20 de novembro de 2026. Use Transfer to local para os espaços de trabalho e Settings → Account → Export data para o arquivo da conta.

O anúncio de que o Conductor está se juntando à Meta confirma que chats antigos e exportação continuarão disponíveis no modo somente leitura. Ele não confirma se as transferências de espaços de trabalho ou os terminais do Cloud continuarão disponíveis nesse período. O Cloud será encerrado em 20 de novembro, quando também começará a exclusão dos dados dos usuários do Cloud.

Para usuários atuais, o Conductor local pode dar tempo para concluir o trabalho em andamento. Trate-o como uma solução temporária, não como seu único backup nem como um substituto permanente.

Quais datas importam no encerramento do Conductor?

Termine as transferências e as etapas de backup que exigem o terminal antes do início do modo somente leitura. Separe essa precaução do prazo documentado para exportar a conta. Em 2026-11-10, o cronograma oficial é:

Data	O que muda	O que fazer
4 de novembro de 2026	Novos usuários não podem mais se cadastrar no Conductor nem baixar o aplicativo. Usuários Pro atuais podem continuar usando os recursos Pro gratuitamente.	Planeje com sua instalação e conta atuais.
13 de novembro de 2026	Os espaços do Cloud passam para somente leitura. Chats antigos e exportação continuam disponíveis, mas não será possível enviar novas mensagens.	Conclua o trabalho interativo antes dessa data. Por precaução, conclua e verifique também as transferências e as etapas de backup que exigem o terminal.
20 de novembro de 2026	O Cloud é encerrado e começa a exclusão dos dados de seus usuários.	Conclua e verifique a exportação separada da conta antes dessa data.
Início de 2027	Termina o período prometido de novos modelos e correções críticas para o Conductor local. Começa sua descontinuação gradual.	Elimine antes as dependências restantes do aplicativo.

O anúncio também promete reembolso para assinantes ativos. Confira o histórico de cobrança separadamente: a promessa não confirma que o dinheiro já chegou à sua conta.

Para uma migração em equipe, use 12 de novembro como meta interna. É uma margem recomendada, não um prazo oficial para desativar transferências. Não planeje supondo que a exportação da conta funcionará até o fim de 20 de novembro.

Como exportar o Conductor Cloud sem perder trabalho pendente

Use as duas formas de exportação e salve arquivos pendentes separadamente enquanto o espaço do Cloud estiver acessível. Verifique cada cópia antes de depender dela. Não suponha que o arquivo da conta restaure arquivos modificados, não rastreados ou ignorados pelo Git.

Registre e salve primeiro o estado de cada espaço

Faça um inventário breve antes de mover qualquer coisa. Registre o nome do espaço, repositório, branch, último commit, pull request aberto e responsável pela verificação.

Pause as edições e os commits dos agentes enquanto registra o estado. Enquanto os terminais do Cloud estiverem acessíveis, execute estas verificações na raiz do repositório de cada espaço. Conclua essa etapa antes de 13 de novembro. O shell é Bash:

git rev-parse --verify HEAD
git status --short --branch --untracked-files=all
git diff HEAD --stat

O primeiro comando mostra o identificador do commit atual. O segundo mostra informações da branch e arquivos modificados ou não rastreados. O terceiro resume as diferenças dos arquivos rastreados em relação ao commit. O Git documenta esses comportamentos nas referências de revisões, estado e diferenças.

Salve a saída completa do segundo comando, git status --short --branch --untracked-files=all, como pre-transfer-status.txt no backup independente. Faça isso antes de criar pastas de backup dentro do repositório. Guarde junto o identificador completo do commit e o nome da branch. Para exclusões e renomeações, registre também quais caminhos não existem no estado final da árvore de trabalho.

Esses comandos inspecionam o estado; não salvam o conteúdo dos arquivos. Envie commits revisados para um repositório remoto aprovado e confirme a branch e o commit nele. Registre a URL desse remoto no inventário, sem segredos incorporados. Para commits que não puder enviar, faça a verificação de backup e restauração por bundle abaixo antes de mover o espaço. Não adicione segredos nem configuração privada ao Git apenas para deixar o estado limpo.

Inspecione .conductor/settings.toml, .conductor/settings.local.toml e .context quando existirem. O Conductor documenta nesses locais os scripts do projeto, a configuração local e as notas de passagem de trabalho sem commit.

Registre comandos de preparação, versões necessárias do ambiente de execução, serviços externos e nomes de variáveis de ambiente. Restaure os valores secretos pelo armazenamento de credenciais aprovado, não por um chamado de migração nem por um prompt do agente.

Antes de transferir um espaço, faça uma cópia independente dos arquivos pendentes necessários. Uma opção documentada é Sync to a local directory, que espelha o espaço do Cloud em uma pasta local. Depois que os arquivos necessários aparecerem, copie-os dessa pasta para um armazenamento de backup separado e aprovado.

Preserve os caminhos relativos e mantenha o inventário com o backup. Inclua os arquivos modificados e não rastreados necessários. Confira separadamente os arquivos ignorados que precisar preservar. Armazene configurações sensíveis apenas em locais aprovados para esses dados.

Abra os arquivos copiados e compare o conteúdo com a origem acessível. Confira a lista com o inventário, incluindo exclusões e renomeações. Não edite a pasta sincronizada nem a trate como seu único backup.

Se faltar um arquivo de texto pequeno, salve todo o conteúdo original em um arquivo local no mesmo caminho relativo. Reabra a cópia e compare. Se qualquer arquivo necessário continuar sem uma cópia local verificada, interrompa a transferência. Isso inclui um binário omitido pela sincronização, como repository.bundle. Fale com o Conductor pelo contato do anúncio enquanto o espaço do Cloud ainda estiver acessível.

Mantenha as edições pausadas até verificar os backups ou atualize o registro de estado e as cópias após a última alteração. Conclua e verifique as etapas de cópia que exigem o terminal antes de 13 de novembro.

Faça backup dos commits que não puder enviar

Salve um backup local do histórico Git antes de transferir uma branch cujos commits não possam ser enviados. O comando bundle do Git empacota referências do repositório e o histórico de commits associado para recuperação sem conexão. Mantenha também as cópias separadas dos arquivos pendentes.

Pause novos commits e atualizações de branches enquanto cria esse retrato do estado. Na raiz do repositório no Cloud, execute este exemplo em Bash. O diretório conductor-history-backup não deve existir:

mkdir conductor-history-backup &&
git for-each-ref --format='%(objectname) %(refname)' refs/heads > conductor-history-backup/branches.txt &&
git bundle create conductor-history-backup/repository.bundle --all

Confira se branches.txt inclui cada branch necessária e o identificador completo do commit registrado no inventário. Copie a pasta inteira para o armazenamento local aprovado usando o método anterior. Mantenha a cópia fora da pasta sincronizada e confirme que o próprio repository.bundle chegou ao Mac. Guarde pre-transfer-status.txt, o inventário e os arquivos salvos com esse backup.

Antes de transferir o espaço, teste a recuperação a partir da cópia local. Abra o Bash na pasta conductor-history-backup copiada. Use um destino restored.git que ainda não exista:

git clone --mirror repository.bundle restored.git &&
git --git-dir=restored.git for-each-ref --format='%(objectname) %(refname)' refs/heads > restored-branches.txt &&
git diff --no-index --exit-code -- branches.txt restored-branches.txt &&
git --git-dir=restored.git fsck

A clonagem em espelho restaura as referências em um repositório bare separado, sem uma árvore com os arquivos de trabalho. A comparação das listas de branches não deve mostrar diferenças. O git fsck não deve informar objetos Git ausentes ou corrompidos.

Confirme os nomes das branches e os identificadores esperados em restored-branches.txt antes de mover o espaço. Pare se qualquer comando falhar ou faltar uma branch necessária. Resolva o problema do backup enquanto o repositório no Cloud estiver acessível.

Proteja o bundle, as listas de branches e as cópias de arquivos pendentes como dados privados do repositório. Repita o procedimento para cada repositório com trabalho não enviado e atualize o backup após novos commits.

Transfira um espaço, verifique e passe ao próximo

Por precaução, conclua e verifique cada transferência antes de 13 de novembro. No Mac, clique com o botão direito em um espaço do Cloud e escolha Transfer to local. As notas da versão 0.93.0 descrevem a transferência do espaço e dos chats para o Mac.

Quando a transferência terminar, abra o espaço local e execute novamente os comandos do inventário. Compare branch, commit, alterações pendentes e conteúdo com o inventário e as cópias independentes verificadas antes da transferência. Abra um chat antigo e a conversa mais recente.

Confira separadamente arquivos não rastreados e a configuração do projeto. Ver o repositório não comprova que todos os arquivos e dependências do ambiente foram preservados.

Restaure as dependências pelo procedimento documentado do projeto. Depois execute o menor teste ou a menor verificação de build que seja útil. Investigue divergências usando o histórico verificado no remoto ou bundle e as cópias independentes. Compare com o espaço original do Cloud apenas se ele continuar acessível.

Repita o processo para todos os espaços necessários, incluindo experimentos pendentes e trabalhos antigos com decisões úteis. Atribua um responsável a cada verificação. Não suponha que outro integrante já exportou o trabalho compartilhado.

Baixe e inspecione o arquivo da conta

Gere o arquivo da conta mesmo que os espaços já apareçam localmente. Abra Settings → Account → Export data e salve o download fora dos diretórios de trabalho do Conductor. Conclua e verifique a exportação antes de 20 de novembro.

Mantenha outra cópia no local de backup aprovado pela equipe. Abra a exportação localmente em um visualizador adequado e confira uma amostra de registros de projetos e conversas. Anote a data da exportação e o material ausente.

Trate esse arquivo como um backup a inspecionar, não como um formato de importação garantido para outra ferramenta. Reconstrua o ambiente com código verificado, arquivos salvos separadamente, configuração, dependências e credenciais.

Se Transfer to local não aparecer ou falhar, escolha o caminho de recuperação correspondente abaixo. Use o remoto aprovado se enviou os commits para ele, ou o espelho verificado se fez o backup com um bundle. Recupere material faltante do Cloud somente se ele continuar acessível. Exporte a conta separadamente, mas não trate isso como prova de que o código pendente pode ser recuperado.

Registre a versão do aplicativo, o espaço afetado e o erro exato. Use o contato de suporte no anúncio do Conductor antes do prazo. Não envie credenciais nem conteúdo sensível das conversas.

Durante o período anunciado de somente leitura, chats antigos e exportação continuam disponíveis. Não faça a recuperação depender de uma nova mensagem, uma transferência ou um terminal do Cloud funcionando depois de 13 de novembro.

Recupere uma cópia de trabalho a partir do backup

Recupere o histórico pelo remoto aprovado se você o enviou, ou por restored.git se criou um bundle. Escolha um caminho e depois siga as etapas comuns para restaurar arquivos e exclusões.

Para commits enviados, abra o Bash em um diretório local de recuperação aprovado. Informe a URL do remoto aprovado sem segredos incorporados. Use o nome da branch sem refs/heads/ e o identificador completo do commit registrado no inventário. Use sua autenticação normal do Git e um diretório recovered-worktree que não exista:

read -r -p "Approved remote URL (no embedded secrets): " RECOVERY_REMOTE &&
read -r -p "Branch from inventory: " RECOVERY_BRANCH &&
read -r -p "Full commit ID from inventory: " RECOVERY_COMMIT &&
mkdir recovered-worktree &&
(
  cd recovered-worktree &&
  git init &&
  git remote add origin "$RECOVERY_REMOTE" &&
  git fetch origin &&
  git switch --create "$RECOVERY_BRANCH" "$RECOVERY_COMMIT" &&
  test "$(git branch --show-current)" = "$RECOVERY_BRANCH" &&
  test "$(git rev-parse --verify HEAD)" = "$RECOVERY_COMMIT" &&
  git status --short --branch --untracked-files=all
)

A etapa fetch busca o histórico remoto. O git switch --create cria a branch local desejada no commit registrado, não no commit mais recente do remoto. Pare se a autenticação falhar, o commit registrado estiver indisponível ou qualquer comparação falhar. Obtenha o commit ausente de um bundle verificado ou de um espaço do Cloud acessível; não o substitua por outro.

Para um backup bundle, abra o Bash no diretório local conductor-history-backup. Informe o nome da branch sem refs/heads/ e o identificador completo do commit do inventário salvo. Use um diretório recovered-worktree que não exista:

read -r -p "Branch from inventory: " RECOVERY_BRANCH &&
read -r -p "Full commit ID from inventory: " RECOVERY_COMMIT &&
git clone --branch "$RECOVERY_BRANCH" restored.git recovered-worktree &&
(
  cd recovered-worktree &&
  test "$(git branch --show-current)" = "$RECOVERY_BRANCH" &&
  test "$(git rev-parse --verify HEAD)" = "$RECOVERY_COMMIT" &&
  git status --short --branch --untracked-files=all
)

O git clone --branch seleciona a branch da cópia de trabalho. O git branch --show-current verifica o nome, e git rev-parse --verify HEAD verifica o commit. O relatório final de estado só aparece após as duas comparações passarem. Pare em caso de erro ou divergência.

Depois que qualquer um dos caminhos terminar corretamente, trabalhe dentro da nova cópia recovered-worktree. Copie os arquivos modificados, adicionados e não rastreados para seus caminhos relativos originais. Restaure separadamente os arquivos ignorados necessários. Não altere as cópias originais do backup.

Use pre-transfer-status.txt e o registro dos caminhos ausentes no estado final da árvore de trabalho para reconstruir exclusões e renomeações. Remova cada caminho registrado como excluído somente da cópia de recuperação, após confirmar que ele estava ausente nesse estado final. Para uma renomeação, restaure o arquivo no novo caminho. Remova o caminho antigo apenas se ele já não existia nesse estado.

Execute novamente os comandos do inventário na raiz da cópia recuperada. Confira cada caminho alterado com o estado salvo e compare o conteúdo com as cópias independentes. Isso restaura o conteúdo da árvore de trabalho, não o estado original da área de preparação. Revise as diferenças antes de preparar alterações ou retomar o agente, e não envie commits ao espelho de backup.

Use o Conductor local como solução temporária

Mantenha o Conductor local para continuar trabalhando enquanto elimina dependências da interface de espaços de trabalho. O anúncio promete novos modelos e correções críticas até o início de 2027, seguido de descontinuação gradual. Isso não amplia o prazo do Cloud de 20 de novembro.

Valide o ambiente de execução depois de transferir um espaço. A documentação dos espaços do Cloud descreve um ambiente isolado Linux conectado ao Mac. Um build que funciona no Cloud não comprova que as mesmas dependências e comandos funcionarão localmente.

Executar localmente também não significa executar o modelo sem conexão. A documentação de privacidade informa que o tráfego de modelos dos espaços locais vai para o provedor configurado.

Considere quando os processos terminam. As perguntas frequentes do Cloud dizem que as sessões locais terminam ao fechar o Conductor ou desligar o Mac. Um espaço transferido não substitui um processo do Cloud que permanece em execução.

Use a transição para tornar o repositório utilizável sem o Conductor. Mantenha instruções de preparação, comandos de teste e notas de passagem de tarefas em arquivos revisados do projeto. Confira os limites do provedor ou a cobrança da API separadamente do acesso gratuito aos recursos Pro.

Retome o trabalho paralelo com Claude Code, Codex ou OpenCode

Comece com o agente de programação que você já usa e retome o trabalho paralelo com árvores de trabalho Git separadas. Um worktree é outra cópia de trabalho do mesmo repositório, normalmente em uma branch diferente.

Esse método atende a quem consegue executar projetos localmente e revisar mudanças com Git. Ele cria diretórios de trabalho separados, não o serviço compartilhado do Conductor Cloud nem toda a sua interface.

Escolha o agente e verifique a autenticação

Instale e autentique o CLI escolhido fora do Conductor antes de transferir uma tarefa. O exemplo com agentes diferentes exige Claude Code e Codex instalados e autenticados. Para usar um único agente, execute o mesmo CLI nas duas árvores de trabalho.

Use o Claude Code para manter sua forma de trabalhar com ele. Execute claude no diretório do projeto e siga as instruções de autenticação do primeiro uso.

Use o Codex CLI para manter seu fluxo com o Codex. Execute codex no diretório do projeto. No primeiro uso, ele oferece login pelo ChatGPT ou outro método disponível.

Use o OpenCode se já depende da configuração de provedores dele ou precisa dessa escolha. Execute opencode e depois use /connect e /models, conforme as instruções de provedores.

Não suponha que credenciais configuradas apenas no Conductor estejam disponíveis para um CLI independente. Confira a conta ativa, o provedor e o modelo antes de liberar uma tarefa real.

Para uma opção separada de API com pagamento por uso, o BetterToken publica guias específicos de Claude Code e Codex. Separe a configuração de acesso aos modelos da recuperação dos espaços. Use a lista de verificações iniciais das APIs de Claude Code e Codex antes de transferir uma tarefa de produção.

Crie duas árvores de trabalho e confira o processo completo

Comece na raiz do repositório local verificado, a partir de um commit conhecido. Este exemplo em Bash cria duas branches a partir do HEAD atual:

git worktree add -b migration/docs ../migration-docs HEAD &&
git worktree add -b migration/tests ../migration-tests HEAD &&
git worktree list

A referência de worktree do Git documenta a criação de branches com -b e a inspeção com list. Confirme que a saída inclui os dois novos diretórios e suas branches.

São cópias novas do estado salvo no commit. Elas não copiam arquivos sem commit nem o estado dos chats do Conductor. Preserve o trabalho pendente de recuperação antes de usar o exemplo.

Use nomes de branch e diretório ainda não utilizados. Se a criação falhar, inspecione o estado existente antes de decidir se deve tentar novamente. Não acrescente --force apenas para contornar o erro.

Os dois comandos seguintes pressupõem que Claude Code e Codex estão instalados e autenticados. Abra duas abas de terminal, ambas inicialmente na raiz do repositório original. Na primeira, inicie o Claude Code:

(cd ../migration-docs && claude)

Na segunda, inicie o Codex:

(cd ../migration-tests && codex)

Para um único agente, use o mesmo comando instalado nos dois diretórios: claude, codex ou opencode. Evite executar dois agentes que editam arquivos no mesmo diretório de trabalho.

Comece cada sessão com este prompt de verificação:

Use read-only tools to inspect this repository.
Report the current directory and Git branch.
Identify the documented setup command and one existing test command.
Cite the repository files that define those commands.
If a command is not documented, say so.
Do not edit files, install packages, commit, or push.

O resultado esperado são dois relatórios vinculados a diretórios e branches diferentes. Cada relatório deve citar arquivos reais do repositório, não inventar um comando de teste genérico. Mantenha os controles normais de aprovação habilitados: um prompt não cria uma barreira de segurança.

Depois que as verificações passarem, autorize a preparação necessária e execute um teste pequeno existente em cada árvore. Em seguida, atribua tarefas independentes, como corrigir a documentação e melhorar um teste separado. Revise cada diff antes de criar commits ou mesclar alterações.

Use as conversas exportadas para escrever uma nota breve de cada tarefa: objetivo, restrições, mudanças concluídas, trabalho restante e último resultado dos testes. Revise instruções e hooks importados antes de reutilizá-los. O guia de auditoria de configuração de agentes traz uma lista útil.

Não confunda uma nova sessão do CLI com o histórico de conversa restaurado. A documentação de importação da OpenAI lista Claude Code e Cursor como fontes para o Codex CLI. Ela não confirma a importação direta de um arquivo da conta do Conductor.

Árvores de trabalho separadas também não criam bancos de dados, contas de serviço ou portas de desenvolvimento independentes. Distribua esses recursos antes de executar builds em paralelo. O próprio Conductor diferencia isolamento dos espaços e barreiras de segurança.

Acompanhe o limite do provedor ou os custos de API de cada sessão ativa. Por exemplo, a documentação de autenticação da OpenAI distingue cobrança por chave de API dos créditos incluídos no ChatGPT. Abrir outra aba de terminal não cria outro limite de assinatura.

Considere a migração concluída somente quando o arquivo abrir, os arquivos e commits necessários estiverem conferidos e uma tarefa local passar nas verificações. Mantenha espaços pendentes na lista até que o responsável os verifique ou registre explicitamente o que não foi possível recuperar.