Microsoft Copilot CLI: como usar o Managed Runtime

O que são o Microsoft Copilot CLI e o Copilot Managed Runtime

O Copilot Managed Runtime é um ambiente gerenciado para apps empresariais internos. O código continua editável, o controle de versão continua sendo Git de verdade, e a Microsoft fornece o runtime hospedado, o login pelo Microsoft Entra, conexões de dados governadas, os mecanismos de preview e implantação e um inventário administrativo.

Pense nele como um prédio comercial com serviços para o seu código. Você ainda decide o que acontece em cada sala. O prédio cuida da portaria, dos serviços essenciais, das normas de segurança, do registro de manutenção e da equipe de instalações. Isso é diferente de uma ferramenta de programação com IA que apenas desenha a planta das salas.

A Microsoft apresenta o SDK como a camada de desenvolvimento para apps internos de linha de negócio. Ele inclui autenticação pelo Entra sem código de identidade personalizado e acesso a mais de 1,500 conectores via JavaScript e TypeScript, embora a política do tenant determine quais conectores e ações o app realmente poderá usar. A visão geral do SDK em versão prévia pública e o anúncio de lançamento ajudam a entender esses limites.

Este guia acompanha o SDK e a CLI disponíveis agora. Copilot Code e Autopilot não são tratados aqui como nomes equivalentes para esse conjunto de ferramentas.

Onde o app realmente fica

A resposta muda conforme o app avança pelo ciclo de vida:

Essa separação faz diferença. O preview pode avançar enquanto a versão em produção permanece estável, e uma falha no build de preview não substitui a última versão bem-sucedida.

Comece pelos requisitos, não pelo código

A maneira mais rápida de perder um dia é descobrir uma restrição de tenant ou licença quando o app já está pronto. Confira estes cinco itens antes de começar.

As opções de cobrança e as políticas administrativas merecem uma decisão orçamentária própria. Consulte a análise separada de preços do Copilot Managed Runtime antes de liberar o acesso para um grupo piloto. Um detalhe operacional precisa ficar claro neste guia: a execução local não é uma brecha gratuita. Ela exige a mesma cobertura de runtime de um usuário final.

O que foi verificado para este guia

O pacote foi verificado de fato. A execução no tenant, não.

Portanto, este artigo não alega um tempo até a primeira página local ou o preview hospedado, nem um erro de build observado, uma identidade do Entra inspecionada, uma chamada de conector executada, uma implantação ou uma cobrança de runtime. As etapas abaixo são o caminho documentado pela Microsoft, não um teste de laboratório disfarçado.

Leve um pequeno app de operações pela CLI

Use um app fictício chamado Ops Intake. A primeira tarefa é modesta: exibir registros de uma fonte aprovada pelo tenant em uma fila somente leitura. Começar com uma operação de leitura torna a primeira revisão de política mais fácil de entender. Só inclua gravações depois de comprovar a identidade, as permissões da fonte, a política de conectores e a cobertura de runtime.

Para facilitar a reprodução, a sequência fixa a versão da CLI verificada em 27 de setembro de 2026. Registre no repositório a versão escolhida pela sua equipe para que uma atualização do pacote em preview não altere o piloto silenciosamente.

npm install -g @microsoft/managed-apps-cli@0.25.1
ms --version

ms auth login
ms app create ops-intake --display-name "Ops Intake"
cd ops-intake

npm install
ms app dev

ms connector list --search SharePoint
ms connector list-actions --connector <allowed-connector-id> --search list
ms app add data-source --connector <allowed-connector-id>

git add .
git commit -m "first ops intake flow"
git push

ms app play --mode preview
ms app build-status
ms app deploy

Veja o que cada transição significa.

1. Entre na conta e crie a estrutura governada

ms auth login abre o login do Microsoft Entra. Em uma máquina sem interface gráfica, a CLI também oferece --device-code. ms app create cria o registro do app, gera a estrutura do projeto e usa, por padrão, um repositório Git gerenciado pela plataforma. O primeiro comando de criação ou inicialização também provisiona o ambiente de desenvolvimento vinculado à identidade do criador, desde que o roteamento permita.

Não escolha o modo de repositório sem avaliar as consequências. O Git gerenciado pela plataforma é o caminho mais curto para começar. Um repositório externo pode estar no GitHub.com ou no GitHub Enterprise Cloud. GitHub Enterprise Server, Azure DevOps e outros provedores não são aceitos nesse fluxo. O modo de repositório fica fixo durante toda a vida do app; para mudá-lo depois, será preciso criar outro app.

2. Execute localmente e registre o primeiro tempo útil

Instale uma vez as dependências geradas com a estrutura e execute ms app dev. O comando lê ms.config.json, inicia o processo de desenvolvimento do projeto e exibe uma URL de execução local. Abra-a no mesmo perfil do navegador usado para acessar o tenant.

Inicie um cronômetro imediatamente antes de ms app dev e pare quando a primeira página utilizável aparecer. Registre à parte as interrupções causadas por permissões do navegador. Chrome e Microsoft Edge podem bloquear o acesso de uma origem pública ao localhost até que o acesso à rede local seja autorizado; essa é uma restrição do navegador, não uma falha no build do aplicativo.

3. Comprove uma leitura governada

ms connector list exibe IDs de conectores, tipo de autenticação, suporte a dados tabulares e o status tanto de Data Loss Prevention quanto de Advanced Connector Policy. Considere essa saída a fonte oficial para o ambiente. A presença de um conector no catálogo da Microsoft não significa que ele está automaticamente liberado no seu tenant.

Para o Ops Intake, selecione uma conexão, um conjunto de dados e uma lista do SharePoint que estejam permitidos; depois, escolha uma operação de leitura ou listagem. O fluxo interativo de ms app add data-source gera modelos e serviços TypeScript tipados em generated/. Chame o método de leitura gerado no app em vez de improvisar um fluxo de token bruto do Graph.

Valide três pontos no navegador:

1. O usuário conectado é a identidade esperada do Entra.
2. O usuário vê apenas os registros já autorizados pelo sistema de origem.
3. O app falha de forma segura quando esse mesmo usuário perde o acesso à fonte.

Compartilhar o app mais tarde não concede acesso aos dados subjacentes. Cada usuário ainda precisa das permissões e da conexão corretas na fonte. Isso é um recurso de segurança, não um incômodo da implantação.

4. Faça commit e push do código-fonte real

Use comandos Git comuns. A CLI do runtime não substitui o controle de versão. Seu commit deve incluir a alteração funcional do aplicativo e os vínculos de conectores gerados que pertencem ao projeto.

A armadilha importante é simples: git push não compila o app. Ele apenas atualiza o código-fonte no repositório remoto oficial.

5. Abra o preview hospedado e examine o build

ms app play --mode preview abre o endpoint estável de preview. Se o commit mais recente enviado ainda não tiver um build, abrir o preview coloca um na fila. Registre o tempo entre a abertura do preview e a disponibilização da nova versão.

Se o build falhar, execute ms app build-status, opcionalmente com --commit <sha>, e salve o motivo completo junto ao commit. Quando uma versão mais recente ainda está em build ou falhou, o preview continua servindo o último build bem-sucedido. A URL de preview é destinada a desenvolvedores com acesso de escrita ao repositório, não a qualquer pessoa que fará uma avaliação.

Você pode executar ms app build quando quiser iniciar um build antes de abrir o preview. Para a maioria das equipes, vale primeiro aprender o comportamento padrão: enviar o código e depois abrir o preview.

6. Implante somente a versão que você inspecionou

ms app deploy promove um build bem-sucedido para o app em produção. A versão em produção é um snapshot fixo: ela não acompanha cada push ou build de preview.

Para uma liberação controlada, registre o SHA do commit, confira o status do build, abra o preview correspondente e então implante esse SHA com ms app deploy --commit <sha>. A mesma opção permite reverter com clareza para um build anterior bem-sucedido, sem reescrever o histórico do Git.

A conta do negócio muda na camada de plataforma

O runtime não torna gratuito o trabalho de criar um aplicativo. Ele muda quais partes sua equipe precisa comprar ou construir separadamente.

O orçamento de software comparável não é irrelevante. A página oficial de preços da Retool informa que o plano Team custa $10 por builder e $5 por usuário interno ao mês, enquanto o Business custa $50 por builder e $15 por usuário interno ao mês. O Copilot Managed Runtime não supera esses valores automaticamente. Ele pode eliminar trabalho de plataforma separado para uma organização que usa Microsoft 365, mas licenças de runtime, créditos, trabalho com conectores e tempo administrativo continuam sendo custos reais.

Use esta equação no piloto antes de concluir que a opção é mais barata:

Custo do piloto = tempo de desenvolvimento + configuração administrativa + cobertura de runtime + trabalho de conectores e dados.

A parcela com maior chance de diminuir é a montagem da plataforma. A que mais tende a surpreender é a cobertura de runtime para cada pessoa que abre o app.

Sete apps internos adequados a esse runtime

Os melhores candidatos são fluxos internos nos quais identidade, dados governados do Microsoft 365 e uma liberação controlada importam mais do que uma vitrine pública.

Cada caso de uso deve começar em modo somente leitura. Uma ação de escrita, um endpoint externo, um conector de terceiros ou um app compartilhado amplamente muda a revisão. A política padrão inclui 18 conectores próprios da Microsoft, não o catálogo inteiro, e bloqueia algumas ações abertas de HTTP, código arbitrário, consultas arbitrárias e plataformas arbitrárias mesmo dentro de conectores aprovados.

Três produtos que vale a pena criar sobre o runtime

O produto mais forte é uma central de onboarding para Microsoft 365. Ela combina a maior demanda medida com um fluxo que naturalmente atravessa identidade, documentos, tarefas, e-mail e transferências entre equipes.

1. Uma central de onboarding para Microsoft 365

Crie um app interno único no qual RH e TI possam consultar o registro aprovado de uma nova contratação, as tarefas pendentes, os links para documentos e os responsáveis. As equipes de operações de RH e serviços de TI pagariam por menos transições esquecidas e por uma trilha de auditoria mais simples.

A demanda é visível: “employee onboarding software” recebe cerca de 590 buscas por mês nos EUA, com intenção comercial e custo por clique de $156.35. A consulta mais específica “best employee onboarding software” recebe 90 buscas mensais e apresentou crescimento anual de 180% nos dados de sugestões.

A menor versão vendável atende a um departamento, lê uma lista aprovada de funcionários, exibe um checklist de tarefas e associa cada tarefa ao responsável. Só adicione ações de conectores depois que o caminho de leitura passar pelos testes de política e permissão.

A ressalva é séria. Dados de RH são sensíveis, as permissões da fonte são fáceis de interpretar errado e fornecedores consolidados de onboarding já cobrem fluxos de RH mais amplos. O produto só ganha quando a governança do Microsoft 365 e a operação nativa no tenant importam mais do que uma longa lista genérica de recursos.

2. Um painel governado de aprovações

Crie uma interface reutilizável de aprovação para equipes de finanças, compras ou operações que tenham um estado de decisão claro, mas contexto de apoio espalhado. O comprador paga por uma análise mais rápida e por um processo controlado de liberação, não por mais um criador de formulários.

“Approval workflow software” recebe cerca de 320 buscas mensais nos EUA, com intenção comercial, custo por clique de $114.86 e crescimento anual de 53% nos dados de sugestões. Essa combinação indica um problema de compra ativo, com espaço para uma implementação focada em Microsoft 365.

O MVP tem um tipo de solicitação, uma fonte aprovada, uma tela de análise somente leitura, histórico de decisões e uma única ação aprovada pela política. Mantenha o modelo de decisão determinístico. Não esconda regras de aprovação em texto gerado.

A ressalva é a política de conectores. Um conector pode estar liberado enquanto uma ação específica continua bloqueada, e políticas de dados clássicas podem se combinar com Advanced Connector Policies, prevalecendo o resultado mais restritivo.

3. Uma avaliação de migração para apps gerenciados

Venda uma avaliação padronizada que analisa um app web interno, personalizado ou gerado por IA, e determina se ele pode migrar para o Copilot Managed Runtime. O comprador é uma organização que usa Microsoft 365, tem um protótipo útil e não quer manter mais uma pilha independente de hospedagem e governança.

“Custom business app development” recebe cerca de 90 buscas mensais nos EUA, com intenção comercial e custo por clique de $84.03. O volume é menor, mas a consulta está próxima de uma contratação de serviços.

O MVP inventaria o repositório do app, as premissas de runtime, os endpoints externos, o código de identidade, as fontes de dados e as ações necessárias. Em seguida, entrega uma decisão de prosseguir, adaptar ou parar e transfere um trecho somente leitura para um ambiente de teste.

A ressalva é a concentração na plataforma. O resultado só é útil para tenants qualificados do Microsoft 365, o comportamento da versão prévia pública pode mudar, e provedores de código-fonte incompatíveis ou recursos externos bloqueados podem transformar uma migração aparentemente simples em uma reconstrução.

O que o Copilot Managed Runtime não resolve

Esta é uma rota promissora para apps internos governados, não uma plataforma universal de aplicativos.

• É um recurso em versão prévia pública, com documentação de pré-lançamento. Trate o comportamento dos comandos e as áreas de política como sujeitos a mudanças.
• Não disponibiliza automaticamente a criação pela CLI. Esse caminho vem desativado por padrão mesmo quando o tenant está qualificado para o runtime.
• Não transforma todos os mais de 1,500 conectores em fontes de dados permitidas. A política do tenant, a política de ações dos conectores, as políticas de dados clássicas e as permissões da fonte continuam determinando o acesso.
• Não transforma um app interno de linha de negócio em um produto público voltado a clientes. O preview é restrito a desenvolvedores com acesso de escrita ao repositório, enquanto o acesso à versão em produção é compartilhado deliberadamente dentro do modelo governado.
• Não aceita qualquer provedor de repositório. O código-fonte externo está limitado ao GitHub.com e ao GitHub Enterprise Cloud, e o modo de repositório não pode ser alterado no mesmo app.
• Não elimina o licenciamento de runtime. A execução local e a execução pelos usuários exigem Power Apps Premium ou Managed Application Copilot Credits com saldo.
• Não oferece aos administradores um registro forense perfeito. A visão administrativa cobre inventário, uso, integridade, conectores, fontes de dados e dependências, mas a Microsoft afirma que ela não mostra por completo os destinos exatos, endpoints dinâmicos, ações executadas ou as permissões efetivas de cada usuário na fonte.
• Não comprova uma implantação feita para esta análise. A ausência do Git Credential Manager, de uma biblioteca Linux para armazenamento de segredos e de um tenant qualificado interrompeu o teste antes do login.

A decisão responsável é específica: use essa opção quando o app for interno, a organização já operar no Microsoft 365 e evitar o trabalho de identidade e governança compensar a adoção de uma plataforma em preview e seus controles de tenant. Escolha outra hospedagem quando precisar de um produto SaaS público, outro provedor de código-fonte, controle da infraestrutura ou um modelo de liberação que seus administradores não possam autorizar.

Perguntas frequentes

O que fazer na segunda-feira

Peça a um Power Platform Administrator que habilite a criação pela CLI para um grupo de teste, confirme a regra de roteamento de ambiente desse grupo e forneça cobertura de runtime a dois usuários de teste. Escolha uma lista não sensível do SharePoint e uma operação somente leitura. Depois, peça a um desenvolvedor que registre quatro fatos no diário do piloto: versão da CLI, tempo até a primeira página local, tempo até o preview hospedado e SHA do commit implantado. Interrompa o piloto se a identidade do Entra, as permissões da fonte ou a política de conectores se comportarem de forma diferente do que foi documentado.

Se você quer esse caminho de app governado projetado e desenvolvido para sua empresa, comece com uma avaliação de sistemas de produção de IA.