Skip to main content
OpenClaw lê uma configuração opcional de ~/.openclaw/openclaw.json. Se o arquivo não existir, o OpenClaw usará padrões seguros. O caminho da configuração ativa deve ser um arquivo comum. As gravações feitas pelo OpenClaw o substituem atomicamente (renomeando para o caminho), portanto, se openclaw.json for um link simbólico, seu destino será substituído em vez de receber a gravação por meio do link — evite layouts de configuração com links simbólicos. Se a configuração ficar fora do diretório de estado padrão, aponte OPENCLAW_CONFIG_PATH diretamente para o arquivo real. Motivos comuns para adicionar uma configuração:
  • Conectar canais e controlar quem pode enviar mensagens ao bot
  • Definir modelos, ferramentas, isolamento ou automação (cron, hooks)
  • Ajustar sessões, mídia, rede ou interface
Consulte a referência completa para ver todos os campos disponíveis. Agentes e automações devem usar config.schema.lookup para consultar a documentação exata de cada campo antes de editar a configuração. Use esta página para obter orientações voltadas a tarefas e a Referência de configuração para consultar o mapa mais abrangente de campos e valores padrão.
Primeiros passos com a configuração? Comece com openclaw onboard para uma configuração interativa ou consulte o guia de Exemplos de configuração para obter configurações completas prontas para copiar e colar.

Configuração mínima

Edição da configuração

Validação estrita

O OpenClaw aceita apenas configurações que correspondam totalmente ao esquema. Chaves desconhecidas, tipos malformados ou valores inválidos fazem o Gateway se recusar a iniciar. A única exceção no nível raiz é $schema (string), para que os editores possam anexar metadados do JSON Schema.
openclaw config schema imprime o JSON Schema canônico usado pela interface de controle e pela validação. config.schema.lookup busca um único nó restrito a um caminho, junto com resumos dos filhos para ferramentas de detalhamento. Os metadados de documentação de campo title/description são propagados por objetos aninhados, curingas (*), itens de matriz ([]) e ramificações anyOf/ oneOf/allOf. Os esquemas de plugins e canais em tempo de execução são mesclados quando o registro de manifestos é carregado. Quando a validação falha:
  • O Gateway não é inicializado
  • Somente os comandos de diagnóstico funcionam (openclaw doctor, openclaw logs, openclaw health, openclaw status)
  • Execute openclaw doctor para ver os problemas exatos
  • Execute openclaw doctor --fix (--repair é a mesma opção; --yes ignora as solicitações de confirmação) para aplicar os reparos
O Gateway mantém uma cópia confiável da última configuração válida após cada inicialização bem-sucedida, mas a inicialização e a recarga dinâmica não a restauram automaticamente — somente openclaw doctor --fix faz isso. Se openclaw.json não passar na validação (incluindo a validação local de plugins), a inicialização do Gateway falhará ou a recarga será ignorada, e o ambiente de execução atual manterá a última configuração aceita. Uma gravação rejeitada também é salva como <path>.rejected.<timestamp> para inspeção. O Gateway bloqueia gravações que pareçam sobrescritas acidentais — remover gateway.mode, perder o bloco meta ou reduzir o arquivo em mais da metade — a menos que a gravação permita explicitamente alterações destrutivas. A promoção para a última configuração válida é ignorada quando uma configuração candidata contém um espaço reservado de segredo ocultado, como *** ou [redacted].

Tarefas comuns

Cada canal tem sua própria seção de configuração em channels.<provider>. Consulte a página específica do canal para ver as etapas de configuração:Todos os canais compartilham o mesmo padrão de política de mensagens diretas:
Defina o modelo principal e os fallbacks opcionais:
  • agents.defaults.models define o catálogo de modelos e atua como a lista de permissões para /model; as entradas de provider/* filtram /model, /models e os seletores de modelos para os provedores selecionados, ainda usando a descoberta dinâmica de modelos.
  • Use openclaw config set agents.defaults.models '<json>' --strict-json --merge para adicionar entradas à lista de permissões sem remover os modelos existentes. Substituições simples que removeriam entradas são rejeitadas, a menos que --replace seja fornecido.
  • As referências de modelos usam o formato provider/model (por exemplo, anthropic/claude-opus-4-6).
  • agents.defaults.imageMaxDimensionPx controla a redução de resolução de imagens de transcrições/ferramentas (padrão: 1200); valores menores geralmente reduzem o uso de tokens de visão em execuções com muitas capturas de tela.
  • Consulte a CLI de modelos para alternar modelos no chat e Failover de modelos para saber mais sobre a rotação de autenticação e o comportamento de fallback.
  • Para provedores personalizados/hospedados localmente, consulte Provedores personalizados na referência.
O acesso a mensagens diretas é controlado por canal por meio de dmPolicy (padrão: "pairing"):
  • "pairing": remetentes desconhecidos recebem um código de pareamento de uso único para aprovação
  • "allowlist": somente remetentes em allowFrom (ou no armazenamento de permissões pareadas)
  • "open": permite todas as mensagens diretas recebidas (requer allowFrom: ["*"])
  • "disabled": ignora todas as mensagens diretas
Para grupos, use groupPolicy ("allowlist" | "open" | "disabled") junto com groupAllowFrom ou listas de permissões específicas do canal.Consulte a referência completa para ver os detalhes de cada canal.
Por padrão, mensagens em grupo exigem menção. Configure os padrões de acionamento por agente. Respostas normais de grupos/canais são publicadas automaticamente; ative o caminho da ferramenta de mensagens para salas compartilhadas nas quais o agente deve decidir quando falar:
  • Menções nos metadados: @menções nativas (tocar para mencionar no WhatsApp, @bot no Telegram etc.)
  • Padrões de texto: padrões seguros de expressões regulares em mentionPatterns
  • Respostas visíveis: messages.visibleReplies pode exigir envios pela ferramenta de mensagens globalmente; messages.groupChat.visibleReplies substitui essa configuração para grupos/canais.
  • Consulte a referência completa para ver os modos de resposta visível, as substituições específicas por canal e o modo de conversa consigo mesmo.
Use agents.defaults.skills como uma linha de base compartilhada e depois substitua a configuração de agentes específicos com agents.list[].skills:
Controle com que agressividade o Gateway reinicia canais que parecem inativos:
  • Os valores exibidos são os padrões. Defina gateway.channelHealthCheckMinutes: 0 para desativar globalmente as reinicializações do monitor de integridade.
  • channelStaleEventThresholdMinutes deve ser maior ou igual ao intervalo de verificação.
  • Use channels.<provider>.healthMonitor.enabled ou channels.<provider>.accounts.<id>.healthMonitor.enabled para desativar as reinicializações automáticas de um canal ou uma conta sem desativar o monitor global.
  • Consulte Verificações de integridade para depuração operacional e a referência completa para ver todos os campos.
Dê aos clientes locais mais tempo para concluir o handshake WebSocket anterior à autenticação em hosts sobrecarregados ou de baixo consumo:
  • O padrão é 15000 milissegundos.
  • OPENCLAW_HANDSHAKE_TIMEOUT_MS ainda tem precedência para substituições pontuais de serviço ou shell.
  • Prefira corrigir primeiro os bloqueios na inicialização/no loop de eventos; este ajuste destina-se a hosts que estão íntegros, mas lentos durante o aquecimento.
As sessões controlam a continuidade e o isolamento das conversas:
  • dmScope: main (compartilhado) | per-peer | per-channel-peer | per-account-channel-peer
  • threadBindings: padrões globais para o roteamento de sessões vinculadas a threads. /focus, /unfocus, /agents, /session idle e /session max-age vinculam, desvinculam, listam e ajustam isso por sessão (o Discord vincula threads; o Telegram vincula tópicos/conversas).
  • Consulte Gerenciamento de sessões para saber mais sobre escopo, vínculos de identidade e política de envio.
  • Consulte a referência completa para ver todos os campos.
Execute sessões de agente em runtimes de sandbox isolados:
Primeiro, compile a imagem — em um checkout do código-fonte, execute scripts/sandbox-setup.sh; em uma instalação pelo npm, consulte o comando docker build embutido em Sandbox § Imagens e configuração.Consulte Sandbox para ver o guia completo e a referência completa para conhecer todas as opções.
O push com suporte de relay para builds públicos da App Store usa o relay hospedado do OpenClaw: https://ios-push-relay.openclaw.ai.Implantações de relay personalizadas exigem um caminho deliberadamente separado de build/implantação do iOS cuja URL de relay corresponda à URL de relay do Gateway. Se estiver usando um build com relay personalizado, defina isto na configuração do Gateway:
Equivalente na CLI:
O que isso faz:
  • Permite que o Gateway envie push.test, sinais de ativação e ativações de reconexão pelo relay externo.
  • Usa uma concessão de envio limitada ao registro, encaminhada pelo aplicativo iOS emparelhado. O Gateway não precisa de um token de relay válido para toda a implantação.
  • Vincula cada registro com suporte de relay à identidade do Gateway com o qual o aplicativo iOS foi emparelhado, impedindo que outro Gateway reutilize o registro armazenado.
  • Mantém builds locais/manuais do iOS usando APNs diretamente. Os envios com suporte de relay aplicam-se somente a builds distribuídos oficiais registrados pelo relay.
  • Deve corresponder à URL base do relay incorporada ao build do iOS, para que o tráfego de registro e envio chegue à mesma implantação do relay.
Fluxo completo:
  1. Instale o aplicativo iOS oficial.
  2. Opcional: configure gateway.push.apns.relay.baseUrl no Gateway somente ao usar um build de relay personalizado e deliberadamente separado.
  3. Emparelhe o aplicativo iOS com o Gateway e permita que as sessões do Node e do operador se conectem.
  4. O aplicativo iOS obtém a identidade do Gateway, registra-se no relay usando o App Attest e o recibo do aplicativo e, em seguida, publica o payload push.apns.register com suporte de relay no Gateway emparelhado.
  5. O Gateway armazena o identificador do relay e a concessão de envio e depois os utiliza para push.test, sinais de ativação e ativações de reconexão.
Notas operacionais:
  • Se você mudar o aplicativo iOS para outro Gateway, reconecte-o para que ele possa publicar um novo registro de relay vinculado a esse Gateway.
  • Se você distribuir um novo build do iOS que aponte para uma implantação de relay diferente, o aplicativo atualizará o registro de relay em cache em vez de reutilizar a origem antiga do relay.
Nota de compatibilidade:
  • OPENCLAW_APNS_RELAY_BASE_URL e OPENCLAW_APNS_RELAY_TIMEOUT_MS ainda funcionam como substituições temporárias por variáveis de ambiente.
  • URLs de relay personalizadas do Gateway devem corresponder à URL base do relay incorporada ao build do iOS; o fluxo de lançamento público da App Store rejeita substituições personalizadas da URL de relay do iOS.
  • OPENCLAW_APNS_RELAY_ALLOW_HTTP=true continua sendo uma alternativa de desenvolvimento limitada ao loopback; não persista URLs HTTP de relay na configuração.
Consulte Aplicativo iOS para ver o fluxo completo e Fluxo de autenticação e confiança para conhecer o modelo de segurança do relay.
  • every: string de duração (30m, 2h). Defina como 0m para desativar. Padrão: 30m.
  • target: last | none | <channel-id> (por exemplo, discord, matrix, telegram ou whatsapp)
  • directPolicy: allow (padrão) ou block para destinos de Heartbeat no estilo DM
  • Consulte Heartbeat para ver o guia completo.
  • sessionRetention: remove das linhas de sessão do SQLite as sessões concluídas de execuções isoladas (padrão: 24h; defina como false para desativar).
  • O histórico de execuções mantém automaticamente as 2000 linhas terminais mais recentes por tarefa; as linhas perdidas mantêm sua janela de limpeza de 24 horas.
  • Consulte Tarefas Cron para ver uma visão geral do recurso e exemplos da CLI.
Ative endpoints HTTP de Webhook no Gateway:
Nota de segurança:
  • Trate todo o conteúdo dos payloads de hooks/Webhooks como entrada não confiável.
  • Use um hooks.token dedicado; não reutilize segredos ativos de autenticação do Gateway (gateway.auth.token / OPENCLAW_GATEWAY_TOKEN ou gateway.auth.password / OPENCLAW_GATEWAY_PASSWORD).
  • A autenticação de hooks usa somente cabeçalhos (Authorization: Bearer ... ou x-openclaw-token); tokens na string de consulta são rejeitados.
  • hooks.path não pode ser /; mantenha a entrada de Webhooks em um subcaminho dedicado, como /hooks.
  • Mantenha desativadas as opções que ignoram a proteção contra conteúdo inseguro (hooks.gmail.allowUnsafeExternalContent, hooks.mappings[].allowUnsafeExternalContent), exceto durante depurações com escopo rigorosamente limitado.
  • Se ativar hooks.allowRequestSessionKey, defina também hooks.allowedSessionKeyPrefixes para limitar as chaves de sessão selecionadas pelo chamador.
  • Para agentes acionados por hooks, prefira níveis de modelos modernos e robustos, além de uma política rigorosa de ferramentas (por exemplo, somente mensagens com isolamento em sandbox quando possível).
Consulte a referência completa para ver todas as opções de mapeamento e a integração com o Gmail.
Execute vários agentes isolados com espaços de trabalho e sessões separados:
Consulte Multiagente e a referência completa para conhecer as regras de vinculação e os perfis de acesso por agente.
Use $include para organizar configurações grandes:
  • Arquivo único: substitui o objeto que o contém
  • Matriz de arquivos: mesclada profundamente em ordem (o último prevalece), com até 10 níveis de aninhamento
  • Chaves irmãs: mescladas após as inclusões (sobrescrevem os valores incluídos)
  • Caminhos relativos: resolvidos em relação ao arquivo que realiza a inclusão
  • Formato do caminho: os caminhos de inclusão não podem conter bytes nulos e devem ter estritamente menos de 4096 caracteres antes e depois da resolução
  • Gravações realizadas pelo OpenClaw: quando uma gravação altera apenas uma seção de nível superior respaldada por uma inclusão de arquivo único, como plugins: { $include: "./plugins.json5" }, o OpenClaw atualiza esse arquivo incluído e mantém openclaw.json intacto
  • Gravação propagada não compatível: inclusões na raiz, matrizes de inclusões e inclusões com substituições em chaves irmãs falham de forma segura nas gravações realizadas pelo OpenClaw, em vez de achatar a configuração
  • Confinamento: os caminhos de $include devem ser resolvidos dentro do diretório que contém openclaw.json. Para compartilhar uma árvore entre máquinas ou usuários, defina OPENCLAW_INCLUDE_ROOTS como uma lista de caminhos (: no POSIX, ; no Windows) de diretórios adicionais que as inclusões podem referenciar. Links simbólicos são resolvidos e verificados novamente; portanto, um caminho que lexicalmente esteja em um diretório de configuração, mas cujo destino real saia de todas as raízes permitidas, ainda será rejeitado.
  • Tratamento de erros: erros claros para arquivos ausentes, erros de análise, inclusões circulares, formato de caminho inválido e comprimento excessivo

Recarga dinâmica da configuração

O Gateway monitora ~/.openclaw/openclaw.json e aplica as alterações automaticamente — não é necessário reiniciar manualmente para a maioria das configurações. Edições diretas no arquivo são tratadas como não confiáveis até serem validadas. O monitor aguarda a estabilização das operações temporárias de gravação/renomeação do editor, lê o arquivo final e rejeita edições externas inválidas sem regravar openclaw.json. As gravações de configuração realizadas pelo OpenClaw usam a mesma validação de esquema antes de gravar (consulte Validação rigorosa para conhecer as regras de sobrescrita/rollback aplicáveis a todas as gravações). Se você vir config reload skipped (invalid config) ou se a inicialização informar Invalid config, inspecione a configuração, execute openclaw config validate e depois execute openclaw doctor --fix para repará-la. Consulte Solução de problemas do Gateway para ver a lista de verificação.

Modos de recarga

O que é aplicado a quente e o que exige reinicialização

A maioria dos campos é aplicada a quente sem indisponibilidade; algumas seções aplicadas a quente reiniciam apenas esse subsistema (canal, cron, heartbeat, monitor de integridade), em vez de todo o Gateway. No modo hybrid, as alterações que exigem a reinicialização do Gateway são tratadas automaticamente.
gateway.reload e gateway.remote são exceções em gateway.* — alterá-los não aciona uma reinicialização. Plugins individuais também podem substituir esta tabela: um plugin carregado pode declarar seus próprios prefixos de configuração que acionam reinicializações (por exemplo, o plugin Canvas integrado reinicia o Gateway para plugins.enabled, plugins.allow e plugins.deny, não apenas para seu próprio plugins.entries.canvas), portanto, o comportamento real depende dos plugins ativos.

Planejamento do recarregamento

Ao editar um arquivo de origem referenciado por meio de $include, o OpenClaw planeja o recarregamento com base na estrutura definida no código-fonte, e não na visualização nivelada em memória. Isso mantém previsíveis as decisões de recarregamento a quente (aplicar a quente ou reiniciar), mesmo quando uma única seção de nível superior reside em seu próprio arquivo incluído, como plugins: { $include: "./plugins.json5" }. O planejamento do recarregamento falha de forma segura se a estrutura de origem for ambígua.

RPC de configuração (atualizações programáticas)

Para ferramentas que gravam a configuração pela API do Gateway, prefira este fluxo:
  • config.schema.lookup para inspecionar uma subárvore (nó de esquema superficial + resumos dos filhos)
  • config.get para obter o snapshot atual mais hash
  • config.patch para atualizações parciais (patch de mesclagem JSON: objetos são mesclados, null exclui, arrays são substituídos quando explicitamente confirmados com replacePaths caso entradas sejam removidas)
  • config.apply somente quando houver a intenção de substituir toda a configuração
  • update.run para uma autoatualização explícita seguida de reinicialização; inclua continuationMessage quando a sessão pós-reinicialização precisar executar um turno de acompanhamento
  • update.status para inspecionar o sentinela de reinicialização da atualização mais recente e verificar a versão em execução após uma reinicialização
Os agentes devem tratar config.schema.lookup como o primeiro recurso para consultar a documentação e as restrições exatas no nível dos campos. Use a Referência de configuração quando precisarem do mapa de configuração mais abrangente, dos valores padrão ou de links para referências específicas dos subsistemas.
As gravações do plano de controle (config.apply, config.patch, update.run) são limitadas a 3 solicitações por 60 segundos por deviceId+clientIp. As solicitações de reinicialização são agrupadas e, em seguida, impõem um período de espera de 30 segundos entre os ciclos de reinicialização. update.status é somente leitura, mas restrito a administradores, pois o sentinela de reinicialização pode incluir resumos das etapas de atualização e trechos finais da saída de comandos.
Exemplo de patch parcial:
Tanto config.apply quanto config.patch aceitam raw, baseHash, sessionKey, note e restartDelayMs. baseHash é obrigatório para ambos os métodos quando um arquivo de configuração já existe (uma primeira gravação sem configuração existente ignora a verificação). config.patch também aceita replacePaths, um array de caminhos de configuração cuja substituição do array é intencional. Se um patch substituir ou excluir um array existente por outro com menos entradas, o Gateway rejeitará a gravação, a menos que esse caminho exato apareça em replacePaths; arrays aninhados em entradas de arrays usam [], como agents.list[].skills. Isso impede que snapshots truncados de config.get sobrescrevam silenciosamente arrays de roteamento ou listas de permissões. Use config.apply quando houver a intenção de substituir toda a configuração.

Variáveis de ambiente

O OpenClaw lê as variáveis de ambiente do processo pai, além de:
  • .env do diretório de trabalho atual (se presente)
  • ~/.openclaw/.env (fallback global)
Nenhum dos arquivos substitui variáveis de ambiente existentes. Também é possível definir variáveis de ambiente inline na configuração:
Se estiver habilitado e as chaves esperadas não estiverem definidas, o OpenClaw executará o shell de login e importará somente as chaves ausentes:
Variável de ambiente equivalente: OPENCLAW_LOAD_SHELL_ENV=1. timeoutMs padrão: 15000.
Referencie variáveis de ambiente em qualquer valor de string da configuração com ${VAR_NAME}:
Regras:
  • Somente nomes em maiúsculas correspondem: [A-Z_][A-Z0-9_]*
  • Variáveis ausentes/vazias geram um erro durante o carregamento
  • Use escape com $${VAR} para obter uma saída literal
  • Funciona em arquivos $include
  • Substituição inline: "${BASE}/v1""https://api.example.com/v1"
Para campos compatíveis com objetos SecretRef, é possível usar:
Os detalhes de SecretRef (incluindo secrets.providers para env/file/exec) estão em Gerenciamento de segredos. Os caminhos de credenciais compatíveis estão listados em Superfície de credenciais SecretRef.
Consulte Ambiente para obter a precedência e as fontes completas.

Referência completa

Para consultar a referência completa campo por campo, consulte a Referência de configuração.
Relacionados: Exemplos de configuração · Referência de configuração · Doctor

Relacionados