Configuração de skills do OpenClaw
Carregamento, instalações, a política de instalação do operador, entradas por skill, listas de permissões por agente, os limites do Workshop e a armadilha das variáveis de ambiente no sandbox
A maior parte do que decide quais skills um agente do OpenClaw vê e como elas são instaladas fica sob uma única chave no arquivo de configuração, com a visibilidade por agente nas entradas dos agentes. A página de referência é longa porque o schema cobre carregamento, instalação, filtragem, o Workshop e uma política de instalação controlada pelo host. Aqui está a superfície inteira, em ordem: carregamento e links simbólicos, preferências de instalação, a política de instalação e como ela falha fechada, a lista de permissões das skills integradas e as entradas por skill, as listas de permissões por agente e o que elas não são, as configurações do Workshop e a armadilha do sandbox.
Carregamento e instalação
- Os diretórios extras são varridos com a menor precedência, abaixo das skills integradas e das de plugins, com expansão do til; os destinos de link simbólico confiáveis são os diretórios reais para os quais uma pasta de skill com link simbólico pode resolver, mesmo quando o link fica fora da raiz configurada, e a documentação recomenda manter essa lista restrita em vez de apontá-la para um diretório home; o monitor, ativado por padrão, atualiza o snapshot das skills quando um arquivo de skill muda.
- Preferências de instalação: preferir instaladores do Homebrew quando disponíveis, um gerenciador de pacotes do Node entre npm, pnpm, yarn e bun que afeta apenas instalações de skills, e uma opção desativada por padrão que permite a clientes administradores confiáveis instalar arquivos zip privados preparados pelo fluxo de upload.
- A política de instalação do operador roda um comando local confiável depois que o OpenClaw preparou a fonte e antes que uma instalação ou atualização continue, para skills do ClawHub, enviadas por upload, do Git e locais, instaladores de dependências e fontes de plugins; ela recebe um objeto JSON que descreve o alvo, a fonte e a origem e responde allow, warn ou block, com um motivo e achados opcionais. Ativada sem um comando válido, as instalações falham fechadas, e o mesmo acontece com um block, uma saída diferente de zero, um tempo limite esgotado, um JSON inválido ou um motivo ausente.
- Um aviso interrompe a instalação antes do commit: comandos interativos pedem que o operador digite o nome do alvo e executam a política de novo, comandos não interativos podem passar uma flag explícita de confirmação, a interface de controle pode revisar avisos de instalação de plugins, outras instalações automáticas ou feitas via Gateway continuam bloqueadas, e force nunca aprova um aviso. Os achados são limitados a cem, o aviso renderizado a quatro mil caracteres, a execução profunda do doctor roda uma sondagem sintética de instalação, e atualizações em massa aplicam a política por alvo.
As listas de permissões de skills do agente são um filtro de visibilidade e carregamento para a descoberta de skills do OpenClaw, os prompts, a descoberta de comandos slash, a sincronização do sandbox e os snapshots de skills. Elas não são uma fronteira de autorização no momento da execução do shell.
Entradas e listas de permissões
A lista de permissões das skills integradas restringe apenas as skills integradas; as skills gerenciadas, de nível de agente e do espaço de trabalho não são afetadas. As entradas por skill são indexadas pelo nome da skill, ou pela chave de skill declarada: uma flag enabled que desativa uma skill mesmo quando integrada ou instalada, e que é o que ativa a skill opcional coding-agent depois que uma CLI suportada está instalada e com login feito; um campo de conveniência para chave de API, para skills que declaram uma variável de ambiente principal, em texto simples ou como referência a um segredo; variáveis de ambiente injetadas na execução do agente apenas quando ainda não estão definidas no processo; e um espaço livre para campos personalizados. A geração de imagens integrada usa as configurações de modelo de mídia e a ferramenta de imagem principal, e não uma entrada. As listas de permissões por agente dão às mesmas raízes de máquina e de espaço de trabalho um conjunto visível diferente por agente: uma base compartilhada nos padrões, herdada pelos agentes que omitem a própria lista, e listas explícitas que substituem totalmente os padrões, sendo que uma lista vazia não expõe nenhuma skill. O aviso importa: se um agente pode rodar exec no host, esse shell ainda pode rodar clientes externos e ler arquivos do host visíveis para o usuário de execução, incluindo registros de clientes MCP, então o isolamento por agente exige sandbox ou isolamento por usuário do sistema operacional, exec negado ou uma lista de permissões de exec restrita e credenciais por agente no servidor MCP.
Workshop, links simbólicos, sandboxes
- Configurações do Workshop: um modo autônomo off, propose ou auto, em que auto, o padrão, usa as ferramentas normais do agente para manutenção direta por turno e semanal, sem varredura de propostas, enquanto propose cria propostas pendentes a partir de correções e de trabalho substancial concluído; uma política de aprovação auto ou pending; um máximo de cinquenta propostas pendentes e em quarentena por agente, dentro de um intervalo de um a duzentos; e um corpo de proposta máximo de quarenta mil bytes, dentro de um intervalo de aproximadamente mil a duzentos mil, com as descrições limitadas rigidamente a 160 bytes.
- As raízes de skills do espaço de trabalho, de agente de projeto, de diretórios extras e integradas são fronteiras de contenção, então uma pasta de skill com link simbólico que resolve para fora da sua raiz é ignorada com uma linha de log, a menos que o destino seja confiável; os diretórios de skills gerenciadas e pessoais aceitam links simbólicos de diretório de skill incondicionalmente, e o Workshop usa o diretório de contenção próprio de cada agente, ignora a lista de destinos confiáveis e rejeita links simbólicos que escapam dele.
- Os valores de variáveis de ambiente e de chave de API por skill valem apenas para execuções no host: dentro de um sandbox eles não têm efeito, então uma skill que depende de uma chave falha com um erro de não configurada, a menos que o sandbox receba a variável separadamente pelo env do sandbox Docker, e usuários com acesso ao daemon do Docker podem ler esses valores pelos metadados do contêiner, então um arquivo de segredo montado ou uma imagem personalizada é a resposta quando essa exposição é inaceitável.
Autoaprendizado do OpenClaw explica as regras de elegibilidade e privacidade por trás do modo autônomo, e como criar uma skill do OpenClaw, o arquivo que o carregador está observando.
Por que a nota sobre a fronteira importa
O schema mistura controles de visibilidade com controles de segurança, e a documentação tem o cuidado de dizer qual é qual: as listas de permissões definem o que é oferecido ao agente, a política de instalação define o que pode ser instalado, e só o sandbox ou a separação por usuário do sistema operacional define o que um shell consegue alcançar. O sandbox do OpenClaw explicado é essa última camada, e plugins do OpenClaw, a superfície de instalação irmã que a política também cobre.
Na Diali
Na Diali, o hub de skills do painel é a fachada deste arquivo: ativar uma skill e colar a chave dela é o que se torna a entrada no assistente, e não há shell no host para editá-la à mão. OpenClaw hospedado na Diali é o assistente, e a página de segurança da Diali descreve a fronteira ao redor de cada um.
- As listas de permissões substituem; nunca mesclam.
- A política de instalação falha fechada em qualquer coisa que não seja um allow limpo.
- As variáveis de ambiente das skills param na parede do sandbox.
Pare de ler sobre isso e crie o seu
Configure um agente, escolha um canal e coloque-o para trabalhar dentro do app que você já deixa aberto.
