Agente Think da Cloudflare ficou sem arquivos: como migrar

Resposta rápida

Se um agente Think atualizado iniciou com o workspace vazio, não apague as tabelas antigas e não tente preencher diretamente as tabelas novas. O Think e as Agent Skills passaram a usar @cloudflare/computer, que grava os arquivos em tabelas diferentes das usadas por @cloudflare/shell. A Cloudflare informa que não existe migração automática; os dados antigos continuam presentes até que você os copie ou remova.

Instale @cloudflare/computer, execute uma única vez o script oficial de cópia no mesmo Durable Object, grave o conteúdo pelo workspace.fs e direcione os arquivos do Think para /workspace. Compare arquivos e operações reais antes de liberar todo o tráfego. Só avalie remover a tabela cf_workspace_default e objetos antigos do R2 depois de validar a cópia e manter uma forma de reversão.

O que mudou em 20 de outubro de 2026

A Cloudflare anunciou que Think e Agent Skills agora usam o Workspace de @cloudflare/computer e suas ferramentas de sistema de arquivos. Ao mesmo tempo, @cloudflare/shell e createExecuteTool foram descontinuados e deixaram de receber desenvolvimento e suporte. A mudança é incompatível para workspaces já preenchidos porque os dois pacotes não compartilham o mesmo esquema de armazenamento.

O Shell cria uma tabela cf_workspace_<namespace>; os agentes Think anteriores usavam por padrão cf_workspace_default. O Computer usa tabelas vfs_ e _vfs_. Os dois conjuntos podem coexistir no mesmo armazenamento do Durable Object durante a migração, mas trocar apenas imports e dependências não move um único arquivo.

Confirme o risco antes do deploy

Procure no projeto imports de @cloudflare/shell, Workspace exportado pelo Think, createExecuteTool, workspaceBash, createWorkspaceTools e ferramentas chamadas list. Na nova integração, o workspace vem de @cloudflare/computer, list virou ls e o workspace padrão tem ferramentas de arquivo, mas não oferece exec até que um backend de execução seja configurado.

Também identifique onde os dados estão. Se a aplicação usava namespace personalizado, D1, SqlBackend próprio, InMemoryFs ou arquivos grandes transferidos ao R2, a migração não é uma simples troca de pacote. A documentação atual informa que o Computer aceita ctx.storage de um Durable Object, ainda não oferece equivalente ao namespace do Shell e mantém uma relação de um workspace por armazenamento do Durable Object.

• Registre a versão implantada e faça inventário dos imports e APIs antigas.
• Liste os namespaces, tabelas cf_workspace_* e integrações com R2 usadas pelo agente.
• Conte arquivos por tipo e selecione amostras de texto, binários, diretórios e links simbólicos.
• Defina um ambiente ou conjunto pequeno de agentes para a primeira migração.
• Prepare rollback para o Worker anterior sem remover dados antigos.

Copie os dados pelo sistema de arquivos oficial

O guia oficial constrói um ShellWorkspace e um Workspace do Computer sobre o mesmo armazenamento, percorre o Shell com glob("/**") e cria cada entrada por workspace.fs. Arquivos devem ser lidos com readFileBytes para preservar bytes; diretórios são criados recursivamente e links simbólicos precisam ter o destino resolvido conforme a regra antiga antes da escrita.

Para Think, use /workspace como raiz de destino: /notes.md no Shell passa a /workspace/notes.md no Computer. Se o Shell guardava arquivos no R2, construa o leitor antigo com o mesmo binding, name ou r2Prefix para que readFileBytes encontre os objetos. Não copie linhas diretamente para vfs_: hashes de chunks, revisões e log de mudanças precisam permanecer consistentes.

• Instale @cloudflare/computer e mantenha @cloudflare/shell apenas durante a janela de cópia.
• Adapte o script publicado pela Cloudflare ao nome, namespace e binding R2 reais do projeto.
• Execute a cópia dentro do Durable Object e grave pelo workspace.fs.
• Use uma marca persistente, como shellMigrated, para impedir repetição em cada onStart.
• Registre sucesso, quantidade de entradas e falhas sem imprimir conteúdo sensível.

Configure execução separadamente dos arquivos

O Workspace padrão do Think fornece read, ls, find, grep, write, edit e delete. A ferramenta exec aparece apenas quando você adiciona um backend. Para JavaScript em um Dynamic Worker, a documentação usa WorkerJavaScriptBackend e exige um Worker Loader binding chamado LOADER. Também existem backends de shell e contêiner, com capacidades e níveis de maturidade diferentes.

Não use a migração para ampliar permissões do agente. Escolha o backend necessário, restrinja módulos, rede e escrita e trate o identificador do backend como configuração confiável do host. A própria documentação do Computer alerta que alguns componentes, como o ContainerBackend, ainda são experimentais mesmo que o pacote principal seja adequado para produção.

Valide antes de trocar todo o tráfego

A cópia oficial não preserva created_at, modified_at nem mime_type. Portanto, não use esses campos como prova de igualdade. Compare caminhos, tipos, tamanhos e hashes calculados a partir do conteúdo; abra amostras binárias e de texto; teste links simbólicos; e execute uma skill que leia e grave um arquivo temporário no novo workspace.

Faça o rollout por uma fração de agentes ou identidades, observando exceções do Durable Object, falhas de leitura, consumo de armazenamento e ferramentas ausentes. Um workspace vazio com as tabelas antigas ainda presentes aponta para migração não executada, raiz errada ou marca shellMigrated gravada cedo demais, não para perda automática dos dados antigos.

• Compare a lista de caminhos na origem e em /workspace no destino.
• Calcule hashes de uma amostra representativa de arquivos antes e depois.
• Teste leitura, edição, criação, exclusão controlada e execução quando houver backend.
• Confirme que Agent Skills encontra seus arquivos sob /workspace/.agents/skills.
• Acompanhe logs e mantenha o Worker anterior disponível durante a janela de validação.

Limpeza exige confirmação explícita

Não remova a tabela antiga no mesmo deploy que faz a cópia. O guia da Cloudflare recomenda validar primeiro e, somente depois, excluir objetos R2 antigos pelos r2_key exatos e eliminar a tabela antiga. Evite apagar um prefixo inteiro: workspaces de outros namespaces podem compartilhar o prefixo do R2.

Mantenha um registro auditável do lote migrado, contagens, hashes de amostra, versão do Worker e momento da limpeza. Em ambientes críticos, retenha um backup pelo prazo definido pela sua política e faça a remoção em uma mudança separada, com responsável e plano de restauração.

Limitações e próxima ação útil

Este guia foi verificado em 21 de outubro de 2026. Ele cobre a transição anunciada para Think e Agent Skills e o script de referência mantido pela Cloudflare. APIs em preview, backends, limitações de armazenamento e o próprio script podem mudar. A página de status ajuda a identificar incidentes amplos, mas não confirma que a cópia local, o namespace, o binding R2 ou o caminho /workspace estejam corretos.

Comece agora por um único Durable Object de teste: inventarie cf_workspace_default, copie para /workspace pelo script oficial, compare caminhos e hashes e rode uma skill representativa. Se tudo estiver correto, automatize um rollout gradual e só agende a limpeza antiga como uma mudança posterior e reversível.

Fontes consultadas

Os links abaixo servem para conferir conceitos, orientações oficiais e o critério editorial usado neste conteúdo.

• Think agents now use a @cloudflare/computer workspaceCloudflare Changelog
• Migrating from @cloudflare/shell to @cloudflare/computerCloudflare on GitHub
• Think toolsCloudflare Docs
• File systemCloudflare Docs
• Cloudflare ComputerCloudflare on GitHub
• Cloudflare StatusCloudflare