O Google usa tecnologia de IA na tradução de conteúdos para seu idioma de preferência. As traduções com IA podem ter erros.

Instalar e configurar a CLI

O CodeMender é um agente autônomo de segurança de código de IA que verifica, valida e corrige vulnerabilidades profundas de cibersegurança na sua base de código. Antes de executar o CodeMender, faça o download da CLI e inicialize as opções do espaço de trabalho.

Arquitetura e modelo de segurança

O CodeMender usa um modelo de execução local:

Mecanismo de raciocínio hospedado: o raciocínio agêntico, a modelagem de ameaças e a lógica de orquestração são executados com segurança no Google Cloud na Gemini Enterprise Agent Platform.
CLI de execução local: o código-fonte nunca sai da estação de trabalho ou do contêiner de CI/CD em massa. A ferramenta de CLI local cm executa leituras de arquivos, verificações de build local e verificações de exploração de prova de conceito (PoC) no seu sandbox local, enviando apenas snippets de código cirúrgicos e resultados de execução de ferramentas para o back-end na nuvem pela API Interactions na Gemini Enterprise Agent Platform.

configuração do ambiente

Para começar a usar o CodeMender, configure seu projeto do Google Cloud , faça o download e instale a CLI, configure suas credenciais e o projeto de destino e inicialize seu espaço de trabalho.

Configuração do projeto e permissões do IAM

Antes de baixar a CLI e configurar as credenciais, verifique se o projeto de destino do Google Cloud está configurado corretamente com as APIs e permissões necessárias.

APIs necessárias

Verifique se as seguintes APIs do Google Cloud estão ativadas no seu projeto:

API Agent Platform (aiplatform.googleapis.com): possibilita o streaming e o gerenciamento de sessões ativas.
API Cloud Resource Manager (cloudresourcemanager.googleapis.com): valida os estados de autenticação do usuário e os metadados do projeto.

Papel predefinido recomendado do IAM

Para executar os comandos da CLI, os usuários precisam receber o seguinte papel do IAM:

Usuário da Agent Platform (roles/aiplatform.user): permite que os usuários criem, transmitam e gerenciem sessões ativas.

Baixar e instalar a CLI do CodeMender

Os binários da CLI do CodeMender são hospedados no Artifact Registry. Escolha a guia do seu sistema operacional para baixar e instalar a CLI.

Linux x86_64

Para baixar e instalar a CLI do CodeMender para Linux (x86_64):

Faça o download do pacote usando um dos seguintes métodos:

gcloud CLI: execute o seguinte comando:

gcloud artifacts generic download \
  --project=cmoc-prod \
  --location=us \
  --repository=codemender-cli-production \
  --package=cm \
  --version=stable \
  --name=cm-linux-amd64.zip \
  --destination=./

curl: execute o seguinte comando:

curl -L -o cm-linux-amd64.zip "https://artifactregistry.googleapis.com/download/v1/projects/cmoc-prod/locations/us/repositories/codemender-cli-production/files/cm%3Astable%3Acm-linux-amd64.zip:download?alt=media"

Instale a CLI:

unzip cm-linux-amd64.zip
chmod +x cm
sudo mv cm /usr/local/bin/cm

Linux ARM64

Para baixar e instalar a CLI do CodeMender para Linux (ARM64):

Faça o download do pacote usando um dos seguintes métodos:

gcloud CLI: execute o seguinte comando:

gcloud artifacts generic download \
  --project=cmoc-prod \
  --location=us \
  --repository=codemender-cli-production \
  --package=cm \
  --version=stable \
  --name=cm-linux-arm64.zip \
  --destination=./

curl: execute o seguinte comando:

curl -L -o cm-linux-arm64.zip "https://artifactregistry.googleapis.com/download/v1/projects/cmoc-prod/locations/us/repositories/codemender-cli-production/files/cm%3Astable%3Acm-linux-arm64.zip:download?alt=media"

Instale a CLI:

unzip cm-linux-arm64.zip
chmod +x cm
sudo mv cm /usr/local/bin/cm

macOS Intel

Para baixar e instalar a CLI do CodeMender para macOS (Intel):

Faça o download do pacote usando um dos seguintes métodos:

gcloud CLI: execute o seguinte comando:

gcloud artifacts generic download \
  --project=cmoc-prod \
  --location=us \
  --repository=codemender-cli-production \
  --package=cm \
  --version=stable \
  --name=cm-darwin-amd64.zip \
  --destination=./

curl: execute o seguinte comando:

curl -L -o cm-darwin-amd64.zip "https://artifactregistry.googleapis.com/download/v1/projects/cmoc-prod/locations/us/repositories/codemender-cli-production/files/cm%3Astable%3Acm-darwin-amd64.zip:download?alt=media"

Instale a CLI:

unzip cm-darwin-amd64.zip
chmod +x cm
mv cm /usr/local/bin/cm

macOS Apple Silicon

Para baixar e instalar a CLI do CodeMender para macOS (Apple Silicon):

Faça o download do pacote usando um dos seguintes métodos:

gcloud CLI: execute o seguinte comando:

gcloud artifacts generic download \
  --project=cmoc-prod \
  --location=us \
  --repository=codemender-cli-production \
  --package=cm \
  --version=stable \
  --name=cm-darwin-arm64.zip \
  --destination=./

curl: execute o seguinte comando:

curl -L -o cm-darwin-arm64.zip "https://artifactregistry.googleapis.com/download/v1/projects/cmoc-prod/locations/us/repositories/codemender-cli-production/files/cm%3Astable%3Acm-darwin-arm64.zip:download?alt=media"

Instale a CLI:

unzip cm-darwin-arm64.zip
chmod +x cm
mv cm /usr/local/bin/cm

Windows x86_64

Para baixar e instalar a CLI do CodeMender para Windows (x86_64):

Faça o download do pacote usando um dos seguintes métodos:

gcloud CLI: execute o seguinte comando no PowerShell:

gcloud artifacts generic download `
  --project=cmoc-prod `
  --location=us `
  --repository=codemender-cli-production `
  --package=cm `
  --version=stable `
  --name=cm-windows-amd64.zip `
  --destination=./

PowerShell: execute o seguinte comando:

Invoke-WebRequest -Uri "https://artifactregistry.googleapis.com/download/v1/projects/cmoc-prod/locations/us/repositories/codemender-cli-production/files/cm%3Astable%3Acm-windows-amd64.zip:download?alt=media" -OutFile cm-windows-amd64.zip

Instale a CLI:

Expand-Archive -Path cm-windows-amd64.zip -DestinationPath ./
# Move cm.exe to a permanent folder and add it to your system PATH (e.g. Environmental Variables)

Windows ARM64

Para baixar e instalar a CLI do CodeMender para Windows (ARM64):

Faça o download do pacote usando um dos seguintes métodos:

gcloud CLI: execute o seguinte comando no PowerShell:

gcloud artifacts generic download `
  --project=cmoc-prod `
  --location=us `
  --repository=codemender-cli-production `
  --package=cm `
  --version=stable `
  --name=cm-windows-arm64.zip `
  --destination=./

PowerShell: execute o seguinte comando:

Invoke-WebRequest -Uri "https://artifactregistry.googleapis.com/download/v1/projects/cmoc-prod/locations/us/repositories/codemender-cli-production/files/cm%3Astable%3Acm-windows-arm64.zip:download?alt=media" -OutFile cm-windows-arm64.zip

Instale a CLI:

Expand-Archive -Path cm-windows-arm64.zip -DestinationPath ./
# Move cm.exe to a permanent folder and add it to your system PATH (e.g. Environmental Variables)

Configurar credenciais e projeto do Google Cloud

Como a CLI do CodeMender interage com o mecanismo de raciocínio hospedado na nuvem pela API Interactions, é necessário configurar as Google Cloud Credenciais padrão do aplicativo (ADC) e especificar o projeto de destino no ambiente.

Para autenticar, execute o comando a seguir e siga as instruções de login:
```
gcloud auth application-default login
```
Defina a variável de ambiente GOOGLE_CLOUD_PROJECT como o ID do projeto do Google Cloud :
```
export GOOGLE_CLOUD_PROJECT="PROJECT_ID"
```
Como alternativa, configure o projeto ativo da CLI gcloud:
```
gcloud config set project PROJECT_ID
```
Substitua PROJECT_ID pelo ID do projeto Google Cloud .

Inicializar o espaço de trabalho

Depois de configurar as credenciais e o projeto de destino, a próxima etapa é inicializar o CodeMender no ambiente local. A inicialização do CodeMender prepara seu espaço de trabalho local criando arquivos de rastreamento de estado e estabelecendo configurações de conexão com o mecanismo de raciocínio hospedado na nuvem.

Execute cm init no diretório raiz da base de código para criar arquivos de rastreamento de estado local e estabelecer configurações de referência:

cm init

Use a flag --verify para testar a conectividade com o mecanismo de raciocínio hospedado na nuvem e verificar as configurações do espaço de trabalho:

cm init --verify

Verificar a conectividade e as permissões do serviço

Para verificar suas credenciais, configuração, Network Reachability e permissões do IAM sem iniciar uma verificação ou modificar seu espaço de trabalho, execute cm health:

cm health

O comando cm health executa quatro verificações sequenciais e para na primeira camada com falha. É possível executar cm health em qualquer diretório, mesmo antes de executar cm init. Ele não grava no disco nem consome a cota do modelo.

Para verificações de simulação de CI/CD automatizadas ou monitoramento sintético programado, use --strict para falhar quando as verificações do IAM para envolvidos no projeto forem ignoradas e --json para gerar um relatório JSON legível por máquina:

cm health --strict --json

A tabela a seguir descreve os códigos de saída cm health:

Código de saída	Camada	Descrição
`0`	—	Todas as verificações de integridade foram aprovadas.
`10`	`credentials`	A CLI não conseguiu adquirir um token OAuth ou do Application Default Credentials válido, ou o servidor rejeitou o token (`401 Unauthorized`).
`20`	`config`	O arquivo `config.yaml` local, a flag `--team-id` ou a variável de ambiente `CM_TEAM_ID` é inválida.
`30`	`reachability`	A CLI não conseguiu acessar o endpoint de API Agent Platform (por exemplo, devido a restrições de DNS, TLS, proxy ou VPC Service Controls).
`40`	`authorization`	O servidor foi alcançado, mas o autor da chamada ou o projeto não tem autorização para executar verificações do CodeMender (por exemplo, permissões `roles/aiplatform.user` ausentes).
`50`	—	A verificação de integridade excedeu a duração de `--timeout` (padrão `30s`).

As seguintes flags são compatíveis com cm health:

Sinalização	padrão	Descrição
`--json`	`false`	Gera um único objeto JSON para a saída padrão, incluindo `status`, `exit_code`, `backend`, `endpoint`, `location`, `project_id`, `agent_id`, `duration_ms`, `layers` e (quando presente) `warnings` e `error`.
`--strict`	`false`	Trata os avisos de verificação de integridade (como verificações de permissão do IAM não verificadas ou ignoradas no nível do projeto) como falhas de código de saída `40`.
`--timeout`	`30s`	Define o tempo limite geral para a sondagem de verificação de integridade.

Parâmetros de configuração (`config.yaml`)

O objetivo principal do config.yaml é alinhar os comportamentos do agente do CodeMender com a segurança, as restrições de ambiente e as necessidades de desempenho do seu sistema local.

Como o agente de IA hospedado executa comandos locais (como criar código, executar testes ou editar arquivos) usando seu cliente daemon local, esse arquivo de configuração atua como o limite que define o que o agente pode e não pode fazer.

Uso

Local: por padrão, a CLI lê esse arquivo em ~/.codemender/config.yaml. É possível substituir o espaço de trabalho e o diretório de configuração definindo a variável de ambiente CM_HOME (por exemplo, CM_HOME=/path/to/custom/dir, que lê /path/to/custom/dir/config.yaml).
Execução: quando você executa comandos como cm find, cm verify ou cm fix, o cliente local lê esse arquivo para configurar parâmetros de segurança, aplicar desvios do sistema e especificar quais arquivos ou diretórios ignorar.

Configurações padrão principais

Confira o que significam os principais parâmetros padrão:

tools.confirm_commands: true
- O que isso significa: por padrão, o CodeMender solicita uma confirmação de [Y/n] no terminal antes de executar comandos do shell (run_command). Quando o cm find é executado com o sandbox no nível do SO ativado (sandbox.enabled: true) e o isolamento de rede padrão (permissive-closed), o espaço de trabalho é montado como somente leitura, e as solicitações de confirmação de comando são ignoradas automaticamente.
- Por que esse é o padrão: o CodeMender pode executar comandos de build, pacotes de testes ou scripts de exploit durante a verificação e a aplicação de patches. Exigir confirmação quando o espaço de trabalho é gravável ou não está em sandbox ajuda a evitar a execução não intencional de comandos no ambiente local.
- Ignorar: transmita -y (ou --yes) para uma única execução ou defina tools.confirm_commands: false em config.yaml para pipelines de CI/CD não interativos.
tools.confirm_writes: true
- O que significa: solicita uma confirmação [Y/n] no terminal antes que o agente do CodeMender grave ou modifique arquivos no disco (write_to_file e search_and_replace).
- Por que esse é o padrão: exigir a confirmação manual impede que o agente faça modificações especulativas ou não intencionais nos arquivos de origem durante cm fix ou cm verify. Defina como false (ou transmita -y / --yes) apenas ao executar em ambientes isolados e descartáveis ou em pipelines de CI/CD automatizados.
execution.interactive_mode: true
- O que significa: ativa as solicitações de terminal interativas durante a execução da ferramenta. Defina como false (ou transmita -y / --yes) em ambientes de CI/CD headless em que nenhum terminal está anexado.
scan.extensions.include: [".py", ".java", ".go", ".js", ".jsx", ".mjs", ".cjs", ".ts", ".tsx", ".c", ".cc", ".cpp", ".cxx", ".h", ".hh", ".hpp", ".hxx", ".inl", ".ipp", ".cs", ".rs", ".kt", ".kts", ".rb", ".php", ".sol", ".tf", ".hcl"]
- O que significa: define a lista explícita de extensões de arquivo que você autoriza o CodeMender a ingerir e analisar ao verificar seu espaço de trabalho. O CodeMender ignora automaticamente qualquer arquivo no repositório com uma extensão não especificada nessa lista.
- Por que esse é o padrão: essa lista usa como padrão as principais linguagens de programação para maximizar a eficiência da verificação e evitar que o agente perca tempo e tokens com arquivos de texto, artefatos de build ou arquivos binários irrelevantes. No entanto, como os aplicativos modernos geralmente incorporam vulnerabilidades em configurações de implantação ou ferramentas de automação, é possível expandir manualmente essa lista padrão em config.yaml para incluir arquivos de configuração, formatos de script e arquivos IaC (por exemplo, scripts de shell, XML, YAML, propriedades e arquivos JSON) para que o CodeMender não os ignore silenciosamente.
scan.exclude_dirs: ["node_modules", "vendor", "dist", "/target", "/obj", "/build", ".gradle"]
- O que isso significa: o CodeMender ignora esses diretórios durante a verificação do espaço de trabalho e a análise de código. As entradas com um / inicial (como /target, /obj e /build) correspondem apenas à raiz da verificação, de modo que os pacotes de origem aninhados com esses nomes não são ignorados.
- Por que esse é o padrão: pastas grandes de dependência ou de build acionam uma latência enorme e uma penalidade de token. Manter esses dados excluídos por padrão garante alto desempenho e tempos de resposta rápidos. É possível personalizar essa lista em config.yaml para incluir ou excluir diretórios específicos de acordo com a estrutura do projeto.
project_paths: []
- O que significa: uma lista de caminhos de diretório que o CodeMender pode acessar (ler/gravar) durante a execução da ferramenta.
- Por que esse é o padrão: por padrão, ele fica vazio, o que restringe o agente à raiz do projeto (ou ao diretório de destino da verificação). Se o processo de build ou teste exigir o acesso a arquivos fora da raiz do projeto, adicione esses caminhos aqui ou transmita --allow-all-paths para uma única execução. As gravações em .git, .hg e .codemender são sempre bloqueadas.
- Diretório de artefatos: o agente também pode gravar em um diretório de artefatos por sessão (~/.codemender/artifacts/<session_id>/ ou o equivalente em $CM_HOME).
- Arquivos temporários: quando o sandbox está ativado, o diretório /tmp do host é sempre bloqueado, mesmo que você adicione /tmp a project_paths. As ferramentas que respeitam TMPDIR usam um diretório temporário dentro do diretório de artefatos.
sandbox:
- O que significa: bloco de configuração para o ambiente de sandbox no nível do processo.
- Subparâmetros:
  - enabled: true: (booleano) ativa ou desativa o sandbox. Se você definir como true (padrão), o agente vai executar as ferramentas dentro do sandbox local. Se você definir como false (ou transmitir --sandbox=false), o agente vai executar as ferramentas diretamente no sistema host sem isolamento no nível do SO.
  - mounts: (objeto)
    - target_dir: ".": (String) o diretório a ser montado como o espaço de trabalho ativo dentro do sandbox. A CLI resolve caminhos relativos em relação à raiz do espaço de trabalho.
  - network: (objeto)
    - profile: "permissive-closed": (string) perfil de acesso à rede de saída dentro do sandbox. Ainda não é possível criar listas de permissões granulares de domínios ou padrões de URL específicos. Perfis compatíveis:
      - permissive-closed (padrão): isolamento completo da rede. O sandbox bloqueia todas as conexões de saída.
      - permissive-open: permite acesso total à rede de saída.
security:
- O que significa: bloco de configuração para políticas de segurança.
- Subparâmetros:
  - protected_files: []: (lista de strings) arquivos ou diretórios adicionais no sistema host que você quer montar como somente leitura dentro do sandbox para protegê-los contra modificações. Oferece suporte à expansão de caminho (~) e caracteres curinga (*). Mesmo quando protected_files está vazio, o sandbox sempre protege .git/hooks, .git/config, .hg/hgrc e .codemender como somente leitura e exclui diretórios de credenciais comuns (~/.ssh, ~/.gnupg, ~/.aws, ~/.config/gcloud, ~/.config/gh, ~/.kube, ~/.docker).
model: "gemini-3.8-flash"
- O que significa: o mecanismo de inteligência padrão que alimenta os ciclos de raciocínio do back-end.
- Por que esse é o padrão: o gemini-3.8-flash oferece o equilíbrio ideal entre velocidade, custo e raciocínio analítico necessários para sugerir patches. Os usuários podem mudar para o gemini-4-argon (Gemini 4 Argon) quando precisarem de um raciocínio mais profundo e complexo.
vcs: { type: "git" }
- O que significa: define o tipo de sistema de controle de versões que seu projeto usa com a chave vcs. Se você não configurar essa opção, a ferramenta vai tentar identificar automaticamente os repositórios Git ou Mercurial. Se você definir vcs como none, a CLI vai gerar um aviso, mas vai continuar a execução sem a funcionalidade do VCS. O CodeMender depende dessa configuração para gerenciar correções de segurança especulativas, rastrear modificações na base de código e se integrar ao repositório local.
- Por que esse é o padrão: o CodeMender é compatível com Git, Mercurial ou configurações personalizadas de VCS. O Git é o padrão, já que é o padrão do setor para rastreamento de controle de versões, garantindo uma integração de diferenças perfeita e segurança de reversão.
build: { command: "make build && make test" }
- O que significa: define o comando exato do shell que o CodeMender executa para compilar e criar seu projeto, além de executar os testes de unidade e regressão.
- Por que esse é o padrão: definir um comando de build e teste é fundamental para o fluxo de trabalho de verificação. Ele permite que o CodeMender compile seu projeto e execute o pacote de testes atual no ambiente de sandbox isolado para provar que o patch de segurança gerado mitiga a vulnerabilidade sem interromper a lógica do aplicativo.

Política de comando (`command_policy.yaml`)

Além do sandbox no nível do SO, é possível definir uma lista de bloqueio de comandos em ~/.codemender/command_policy.yaml (global) e <project>/.codemender/command_policy.yaml (específico do projeto). Quando os dois arquivos estão presentes, o CodeMender mescla as regras deles.

Na primeira execução, o CodeMender cria um modelo comentado em ~/.codemender/command_policy.yaml. É possível remover a marca de comentário ou adicionar regras em duas chaves:

block: uma lista de nomes binários para bloquear em todos os pipelines de shell, subshells e substituições de comando (por exemplo, curl, wget, ssh, sudo, rm).
block_patterns: uma lista de expressões regulares que correspondem a cada segmento de comando (por exemplo, '\bgit\s+(push|commit|rebase|reset\s+--hard|clean)\b').

Para ignorar a aplicação de command_policy.yaml em uma única invocação de comando, transmite a flag --allow-all-commands.

Política de comando (`command_policy.yaml`)

Na primeira execução, o CodeMender cria um modelo comentado em ~/.codemender/command_policy.yaml. É possível remover a marca de comentário ou adicionar regras em duas chaves:

block: uma lista de nomes binários para bloquear em todos os pipelines de shell, subshells e substituições de comando (por exemplo, curl, wget, ssh, sudo, rm).
block_patterns: uma lista de expressões regulares que correspondem a cada segmento de comando (por exemplo, '\bgit\s+(push|commit|rebase|reset\s+--hard|clean)\b').

Para ignorar a aplicação de command_policy.yaml em uma única invocação de comando, transmite a flag --allow-all-commands.

Sandbox de execução

Para proteger sua estação de trabalho contra modificações não intencionais de arquivos ou efeitos colaterais inesperados de ferramentas, a CLI do CodeMender é executada em um sandbox no nível do SO por padrão. É possível desativar o sandbox de forma permanente na configuração ou ignorá-lo por comando usando flags da CLI.

Embora esse sandbox ofereça uma camada inicial de defesa na estação de trabalho, ele oferece uma proteção de segurança mais fraca do que executar o agente em uma máquina virtual (VM) totalmente isolada:

Linux: usa namespaces de kernel (CLONE_NEWNS, CLONE_NEWUSER etc.) e filtros seccomp para isolar pontos de montagem e restringir chamadas do sistema.
macOS: usa o mecanismo sandbox-exec (Seatbelt) integrado.
Windows (experimental): usa o isolamento AppContainer e as listas de controle de acesso (ACLs). O sandbox no Windows é experimental e pode exigir privilégios de administrador ou ser incompatível com algumas configurações do sistema.

Comportamento do sandbox

Quando o sandbox está ativo:

Isolamento do sistema de arquivos: o agente só pode acessar arquivos em diretórios permitidos. Durante cm find, o espaço de trabalho e as raízes permitidas são montados como somente leitura. Assim, os comandos só podem gravar no diretório de artefatos por sessão. Em todos os comandos (incluindo cm verify e cm fix), .git/hooks, .git/config, .hg/hgrc e .codemender são montados como somente leitura para que os comandos em sandbox não possam instalar hooks do Git ou do Mercurial nem modificar a configuração do CodeMender.
Isolamento de rede: o sandbox bloqueia o acesso de saída à rede por padrão (sandbox.network.profile: "permissive-closed"). Isso impede que o agente (ou as ferramentas de build que ele invoca) faça conexões externas inesperadas ou transmita dados para fora do espaço de trabalho.
Isolamento de credenciais e secrets: o sandbox exclui diretórios comuns de credenciais de host (~/.ssh, ~/.gnupg, ~/.aws, ~/.config/gcloud, ~/.config/gh, ~/.kube, ~/.docker e outros) e remove variáveis de ambiente que correspondem a padrões de secrets (*_TOKEN, *_SECRET, *_KEY, *_PASSWORD, *_CREDENTIALS e sufixos semelhantes) antes de executar comandos.

Acesso à rede durante a criação e a validação

Como o sandbox ativa o isolamento de rede por padrão (sandbox.network.profile é definido como permissive-closed), o agente não pode acessar a Internet durante a execução da ferramenta.

Isso introduz limitações para projetos que exigem a busca de dependências externas durante as etapas de build ou verificação (por exemplo, executar npm install, pip install ou go get como parte do build.command). Se o processo de build tentar acessar serviços da Web externos, ele vai falhar.

Como processar dependências de rede

Se o projeto exigir acesso à rede para builds ou testes, você terá as seguintes opções:

Pré-busca de dependências: instale todas as dependências necessárias no sistema host antes de executar os comandos cm para que o comando de build não precise de acesso à rede.
Ativar o acesso à rede no sandbox: mude o perfil de rede no config.yaml para permitir conexões de saída:
```
sandbox:
  network:
    profile: "permissive-open"
```
Observação: ainda não é possível criar uma lista de permissões granular de domínios ou padrões de URL específicos (como permitir apenas npmjs.org). O permissive-open concede acesso de saída total ao sandbox.
Desativar o sandbox para uma execução: execute o comando com a flag --sandbox=false para desativar o sandbox no nível do SO (incluindo o isolamento de rede) para essa execução.

Configuração do sandbox

É possível configurar e controlar o sandbox e os limites de segurança usando as seguintes opções:

Configuração persistente (config.yaml e command_policy.yaml): personalize o comportamento do sandbox, as montagens do sistema de arquivos, o acesso à rede e as listas de bloqueio de comandos em config.yaml e command_policy.yaml. Consulte Parâmetros de configuração e Política de comando para mais detalhes.
Controlar o sandbox no nível do SO (--sandbox): ative ou desative explicitamente o sandbox no nível do SO para uma única execução transmitindo --sandbox=true ou --sandbox=false para cm find, cm verify, cm fix ou cm session resume.
Ignorar limites de caminho (--allow-all-paths): desativa a verificação de limite de caminho do espaço de trabalho para uma única execução, permitindo que as ferramentas do agente acessem caminhos fora da raiz do projeto e do project_paths configurado (combine com --sandbox=false para acessar caminhos do host que não estão montados no sandbox).
Ignorar política de comando (--allow-all-commands): desativa a aplicação da lista de bloqueio de command_policy.yaml para uma única execução.

Como escolher um nível de isolamento

Dependendo dos seus requisitos de segurança e do ambiente de desenvolvimento, você pode escolher o nível de isolamento adequado para executar a CLI do CodeMender.

Método	Descrição	Vantagens	Desvantagens
Sandbox integrado (nível do SO)	Ativado por padrão. É possível desativá-lo no arquivo `config.yaml` ou ignorá-lo usando flags da CLI. Usa recursos integrados do SO (namespaces/seccomp, `sandbox-exec`, `AppContainer` (experimental)) para isolar a execução.	Leve; sem sobrecarga de inicialização; acesso direto às ferramentas do espaço de trabalho local com controle detalhado. Recomendado para o desenvolvimento local diário.	A segurança depende dos recursos do kernel do SO; menos isolado do que uma VM completa; o suporte ao Windows é experimental e pode exigir privilégios de administrador ou ser incompatível com algumas configurações.
Contêineres	Executar o agente em um contêiner (por exemplo, Docker).	Bom isolamento; ambiente padronizado.	Requer ambiente de execução de contêiner; pode ser pesado; não permite interação direta com ferramentas na máquina local.
VMs completas	Executar o agente em uma VM dedicada.	Segurança máxima; isolamento total.	Alta sobrecarga de recursos; inicialização lenta; não permite interação direta com ferramentas na máquina local.

Telemetria

Para monitorar e melhorar a integridade do produto, coletamos dados de telemetria anônimos pela CLI. Todos os dados coletados são totalmente anonimizados, incluindo métricas de uso básico e diagnósticos de desempenho. A telemetria nunca coleta nem transmite código-fonte, conteúdo de arquivos, descobertas, patches ou identidades de usuários.

Por padrão, a telemetria está ativada. Se quiser desativar a telemetria, defina a variável de ambiente CM_TELEMETRY_OPT_OUT como 1 ou true.

Como atualizar a CLI

O CodeMender tem um mecanismo de atualização integrado para garantir que você esteja executando a versão mais recente da CLI.

Verificações de atualização automática

Por padrão, a CLI do CodeMender verifica automaticamente se há atualizações em segundo plano quando você executa comandos:

Limitação: para minimizar a sobrecarga, a verificação automática é executada no máximo uma vez a cada 24 horas.
Terminal interativo (TTY) obrigatório: a CLI só verifica se há atualizações e solicita que você as faça quando está em execução em um terminal interativo. Em ambientes não interativos (como pipelines ou scripts de CI/CD), a verificação é ignorada e um aviso é registrado em stderr no máximo uma vez por dia.
Solicitação: se uma nova versão estiver disponível, você vai receber uma solicitação em stderr: none 🆕 A new CodeMender release is available: 1.1.0 Update now? (y/N): Se você escolher sim (y ou yes), o CodeMender vai fazer o download da atualização, substituir o binário e sair. Você precisa executar o comando novamente para que ele seja executado com a nova versão. Se você escolher "não", a atualização será ignorada e o comando original será executado.
Tolerância off-line: se você estiver off-line ou o repositório de versões estiver inacessível, a verificação vai falhar silenciosamente, e o CodeMender vai continuar executando o comando.
Ignorar: é possível ignorar a verificação de atualização automática transmitindo a flag --yes ou -y para qualquer comando.

Atualizações manuais (`cm update`)

Para forçar o CodeMender a verificar e aplicar atualizações imediatamente, execute o comando update:

cm update

O comando cm update:

Ignora a limitação de 24 horas.
Faz o download e aplica a atualização imediatamente sem solicitar (não interativo).
Não requer um terminal interativo (seguro para scripts e gerenciamento de configuração).

Se a CLI estiver instalada em um diretório do sistema que exige permissões elevadas, execute a atualização com sudo:

sudo cm update

Instalar e configurar a CLI Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

Arquitetura e modelo de segurança

configuração do ambiente

Configuração do projeto e permissões do IAM

APIs necessárias

Papel predefinido recomendado do IAM

Baixar e instalar a CLI do CodeMender

Linux x86_64

Linux ARM64

macOS Intel

macOS Apple Silicon

Windows x86_64

Windows ARM64

Configurar credenciais e projeto do Google Cloud

Inicializar o espaço de trabalho

Verificar a conectividade e as permissões do serviço

Parâmetros de configuração (config.yaml)

Uso

Configurações padrão principais

Política de comando (command_policy.yaml)

Política de comando (command_policy.yaml)

Sandbox de execução

Comportamento do sandbox

Acesso à rede durante a criação e a validação

Como processar dependências de rede

Configuração do sandbox

Como escolher um nível de isolamento

Telemetria

Como atualizar a CLI

Verificações de atualização automática

Atualizações manuais (cm update)

Instalar e configurar a CLI

Parâmetros de configuração (`config.yaml`)

Política de comando (`command_policy.yaml`)

Política de comando (`command_policy.yaml`)

Atualizações manuais (`cm update`)