ClawSweeper: Bot Codex OpenClaw Triagem 7.000 Issues GitHub Sem Erros

OpenClaw, o projeto de assistente de IA de código aberto, acumulou mais de 7.000 issues e pull requests abertos até abril de 2026. A maioria dos mantenedores nessa posição declararia falência do rastreador de bugs ou contrataria uma equipe de triagem. Os mantenedores do OpenClaw construíram um bot em vez disso. O ClawSweeper agora revisa cada issue e PR aberto em um cronograma contínuo, elabora uma proposta de fechamento, com autoria do Codex, quando a evidência é forte, e aplica esses fechamentos através de uma linha de execução separada que só é executada quando a proposta ainda é válida.

É também um estudo de caso de contenção. O ClawSweeper não fecha automaticamente por palpite, nunca mexe em itens criados por mantenedores e se recusa a aplicar qualquer alteração se a revisão subjacente deixou lixo na árvore de trabalho.

💡

Para equipes de API que executam SDKs de código aberto ao lado de seus produtos comerciais, o design é uma referência útil, mesmo que você nunca adote o bot em si. Se você mantém documentação pública de API no Apidog e espelha a mesma especificação OpenAPI em um repositório GitHub para contribuições da comunidade, você provavelmente observou issues obsoletas se acumularem da mesma forma.

botão

Este guia detalha o que o ClawSweeper faz, como as três linhas funcionam juntas, as regras de segurança que o impedem de fechar coisas que não deveria, e a configuração do Codex que alimenta cada revisão. Para informações sobre o modelo que faz o trabalho pesado, consulte o que é GPT-5.5.

Em resumo

ClawSweeper é o bot de manutenção do OpenClaw para openclaw/openclaw, escaneando aproximadamente 7.000 itens abertos em um cronograma contínuo.
Três linhas: um agendador escolhe o que revisar, a linha de revisão elabora propostas de fechamento, a linha de aplicação as executa a cada 15 minutos.
Codex com gpt-5.5, alto raciocínio, camada de serviço rápida e um tempo limite de 10 minutos por item escreve as revisões.
Os fechamentos ocorrem apenas para seis casos específicos: implementado, não reproduzível, duplicado, fora do escopo, incoerente ou obsoleto há mais de 60 dias.
Itens criados por mantenedores, itens com PRs de referência abertos e rótulos protegidos nunca são fechados automaticamente.
O bot fechou 10.217 itens via automação no total, mas a semana mais recente mostra uma taxa de fechamento de 0,1% por passagem de revisão; ele tende fortemente a deixar as coisas abertas.
A licença é MIT, a stack é TypeScript em Node 24 com pnpm, e as operações são executadas através de um GitHub App.

O problema de manutenção que o ClawSweeper resolve

OpenClaw se autodenomina “seu assistente pessoal de IA. Qualquer SO. Qualquer plataforma. Do jeito lagosta.” Esse posicionamento atraiu uma vasta comunidade rapidamente: 3.546 issues abertas e 3.457 pull requests abertos a partir do snapshot mais recente do painel em 27 de abril de 2026. Muitos desses itens referenciam comportamentos corrigidos há três releases, duplicam threads mais antigas ou descrevem recursos agora mais adequados ao ecossistema de plugins e habilidades do OpenClaw do que ao repositório principal.

A triagem manual nesse volume não é realista. Fechar a coisa errada também é caro, porque os contribuidores que se sentem ignorados param de contribuir. O ClawSweeper resolve isso separando a etapa de decidir o que fechar da etapa de executar o fechamento, e gastando a maior parte de sua energia em itens onde a resposta é claramente duplicada ou incoerente.

As três linhas

O ClawSweeper se divide em três processos independentes. Cada um registra em seu próprio diretório de relatórios e pode ser pausado sem afetar os outros.

Agendador

O agendador decide quais issues e PRs são revisados e com que cadência. Do README: “Itens novos e ativos recebem mais atenção; itens mais antigos e inativos retornam a uma cadência mais lenta.” Na prática, isso significa itens ativos a cada hora, itens com menos de 30 dias diariamente e issues mais antigas semanalmente. A cadência é intencional. Você deseja revisitar um novo relatório de bug frequentemente, caso mais evidências apareçam, e um antigo raramente, porque é improvável que a resposta mude.

Linha de revisão

A linha de revisão é onde o Codex se destaca. O ClawSweeper seleciona um item, constrói um fragmento de contexto com o título, corpo, comentários e um snapshot do estado do repositório em main, e então entrega o fragmento ao Codex. O Codex retorna um relatório markdown estruturado com um de três vereditos: manter aberto, fechar porque X, ou evidência insuficiente. O README é direto sobre o escopo: “A revisão é apenas uma proposta. Nunca fecha itens.”

Os relatórios ficam em items/ até que a linha de aplicação os consuma, e isso confere ao sistema sua propriedade de segurança. Um humano pode ler cada fechamento proposto no repositório antes que seja aplicado.

Linha de aplicação

A linha de aplicação executa a cada 15 minutos. Ela percorre items/, puxa o relatório mais recente para cada issue ou PR aberto, e revalida a proposta: o relatório ainda é consistente com o estado atual do issue (sem novos comentários, sem rótulo de mantenedor, sem PR de referência aberto na última hora), e é recente o suficiente para agir? Se sim, a linha de aplicação fecha o item, posta a explicação, com autoria do Codex, como um comentário e move o relatório para closed/. Se algo mudou, o relatório é descartado e o agendador reconsidera o item na próxima passagem.

Essa divisão é a escolha de design mais importante no projeto. O Codex nunca toca diretamente no GitHub, e a linha de aplicação nunca raciocina sobre a validade do fechamento; ela aplica a proposta sob novas condições.As regras de fechamento

O ClawSweeper propõe fechamentos apenas para itens que se enquadram em uma das seis categorias específicas, retiradas diretamente do README:

“implementado no main atual”
“não reproduzível no main atual”
“duplicado ou substituído por um issue/PR canônico”
“concreto, mas não acionável neste repositório de origem” (mais adequado para habilidades ou trabalho com plugins do ClawHub)
“incoerente o suficiente para que nenhuma ação possa ser tomada”
“issue obsoleto com mais de 60 dias com poucos dados para verificar”

Qualquer outra situação, incluindo bugs reproduzíveis, solicitações de recursos válidas, reproduções parciais e trabalho real, mas sem prioridade, mantém o item aberto. A taxa de fechamento de 0,1% na passagem de revisão mais recente (4 fechamentos propostos em 3.478 issues revisados) mostra o quão agressivamente o prompt evita falsos positivos.

Algumas proteções são adicionadas às regras de fechamento:

Itens criados por mantenedores nunca são fechados. Se um mantenedor abre um issue, o bot o deixa em paz, independentemente da sua obsolescência.
PRs de referência abertos bloqueiam o fechamento. Se o issue #4321 tem um PR aberto com Closes #4321 no corpo, o ClawSweeper espera.
Rótulos protegidos ignoram o bot completamente. Marque um issue como keep-open (ou qualquer lista de rótulos que os mantenedores configurarem) e o agendador o ignorará.

Configuração do Codex

A configuração do Codex é a parte que mais vale a pena ser adotada por qualquer equipe que esteja construindo sua própria automação:

gpt-5.5

Alguns detalhes são importantes aqui. O modo de alto raciocínio detecta os duplicados que parecem óbvios para um humano após vinte segundos, mas exigem a busca por cinco threads ligadas para verificar. A camada de serviço rápida mantém o custo previsível em um backlog de 7.000 itens. O tempo limite de 10 minutos é uma interrupção definitiva, não um aviso; um item que leva mais tempo é descartado para a próxima passagem em vez de bloquear a fila.

O ambiente Codex também é executado sem tokens de gravação do GitHub. O README afirma claramente: “As revisões falham se o Codex deixar mudanças rastreadas ou não rastreadas para trás.” Isso força o revisor a se comportar como um analista somente leitura; qualquer efeito colateral é um bug, não um recurso.

Se você deseja usar o mesmo modelo interativamente antes de conectá-lo a um bot, o CLI do Codex é o caminho gratuito mais fácil para o GPT-5.5. Para um modelo de custo sobre acesso programático à API, consulte a análise de preços do GPT-5.5 e o guia de uso da API do GPT-5.5.

Configuração local

Clonar o ClawSweeper e executá-lo localmente é simples. O repositório espera Node 24 e pnpm via corepack:

git clone https://github.com/openclaw/clawsweeper.git
cd clawsweeper
source ~/.profile
corepack enable
pnpm install
pnpm run build

Alguns segredos precisam estar presentes antes que as linhas possam iniciar:

OPENAI_API_KEY: autentica o Codex para a linha de revisão.
CLAWSWEEPER_APP_ID: ID do GitHub App (3306130 para a instalação de produção).
CLAWSWEEPER_APP_PRIVATE_KEY: a chave privada usada para gerar tokens de instalação de curta duração.
OPENCLAW_GH_TOKEN: opcional, retorna a um token de acesso pessoal quando a rota do App falha.

Você pode executar a linha de revisão em qualquer repositório que possua. A linha de aplicação se limita intencionalmente às operações de escrita em openclaw/openclaw, a menos que você reconfigure as permissões do GitHub App.

Para equipes que preferem uma chave de API paga, mas desejam o mesmo comportamento do Codex, os caminhos gratuitos do GPT-5.5 descrevem alternativas que passam por créditos de teste ou gateways agregadores.

Snapshot do painel

O README inclui um painel público que é atualizado a cada passagem de aplicação. A partir do snapshot mais recente:

7.003 itens abertos no total (3.546 issues + 3.457 PRs)
3.478 issues revisados nos últimos 7 dias
4 fechamentos de issues propostos (0,1% dos revisados)
10.217 itens totais fechados por automação desde o lançamento

O número de 0,1% é revelador. O ClawSweeper não está otimizando para a caixa de entrada de issues vazia; ele está otimizando para “nunca fechar algo que um contribuidor defenderia se perguntado.” Ao longo de mais de 10.000 fechamentos, essa postura conservadora é o que manteve o projeto credível o suficiente para que os contribuidores continuassem abrindo novos issues.

Por que isso importa para equipes de API

A maioria dos produtos de API no GitHub segue o mesmo caminho do OpenClaw. O SDK ou a especificação reside em um repositório público, o rastreador de issues se enche de relatórios de bugs e solicitações de recursos mistos, e a triagem fica atrasada. Se você publica uma especificação OpenAPI do Apidog e aceita contribuições da comunidade no GitHub, a arquitetura do ClawSweeper é portátil. As partes valiosas não são os prompts, pois estes estão ligados ao domínio do OpenClaw. As partes valiosas são a separação das linhas, as regras rígidas de fechamento e a política de executar o Codex sem acesso de escrita.

Você pode implementar a mesma abordagem em três etapas:

Execute um trabalho de revisão baseado em Codex em uma amostra do seu rastreador. Faça-o produzir relatórios markdown sem fazer commit de nada.
Adicione as regras de segurança: nunca feche itens de mantenedores, respeite rótulos protegidos, adie para PRs abertos.
Adicione uma linha de aplicação somente quando os relatórios de revisão parecerem corretos ao serem lidos manualmente. Configure-a para fechar no máximo alguns por dia até que a confiança seja estabelecida.

Se você está validando a superfície da API que esses issues descrevem, o Apidog lida com o lado do contrato. O mesmo documento OpenAPI impulsiona servidores mock, testes automatizados e a documentação que seus contribuidores leem antes de registrar um bug. Emparelhar um bot de triagem com uma especificação rigidamente versionada geralmente reduz a taxa de issues duplicados pela metade antes mesmo de o bot ser executado. Baixe o Apidog se você quiser começar com a disciplina da especificação.

Limitações e escolhas de design

Algumas coisas que o ClawSweeper deliberadamente não faz:

Ele não escreve código. Sem PRs, sem patches, sem comentários de revisão sugerindo correções. Esse trabalho pertence a outros bots do OpenClaw.
Ele não raciocina sobre prioridade. O fechamento é binário; nada é “despriorizado” ou rotulado pelo bot.
Ele não aprende com fechamentos anteriores. Cada revisão começa do zero em relação ao main. Decisões anteriores aparecem apenas como relatórios históricos em closed/, não como dados de ajuste fino.

Essas escolhas são o motivo pelo qual o bot permanece previsível. Elas também deixam espaço para automação adjacente, como um bot rotulador, um pinger de PRs obsoletos ou um redator de notas de release, sem interferir no escopo restrito do ClawSweeper.

FAQ (Perguntas Frequentes)

Com que frequência o ClawSweeper fecha issues automaticamente? A linha de aplicação é executada a cada 15 minutos, mas a maioria dos ciclos não produz fechamentos. A taxa de fechamento de 0,1% por revisão em 27 de abril de 2026 significa aproximadamente 4 fechamentos em 3.478 issues revisados ao longo de uma semana. Para informações sobre o modelo por trás das revisões, consulte o que é GPT-5.5.

Posso executar o ClawSweeper no meu próprio repositório? Sim. Clone o repositório, configure seu próprio GitHub App com acesso de leitura/escrita no alvo, e aponte CLAWSWEEPER_APP_ID e CLAWSWEEPER_APP_PRIVATE_KEY para ele. A revisão de repositórios de outras pessoas é somente leitura por padrão.

O ClawSweeper requer um plano pago da OpenAI? A linha de revisão autentica via OPENAI_API_KEY, que é uma credencial de API paga. Se você deseja apenas executar revisões interativamente em vez de em escala, o CLI do Codex em um plano gratuito do ChatGPT funciona.

O que impede o Codex de fechar bugs reais? Três coisas. A lista restrita de regras de fechamento, as exclusões de mantenedores e rótulos protegidos, e a etapa de revalidação da linha de aplicação que descarta qualquer proposta onde o issue subjacente tenha mudado desde a revisão.

O ClawSweeper é de código aberto? Sim, licenciado sob MIT, com o código-fonte no GitHub em openclaw/clawsweeper. O projeto pai OpenClaw é um repositório separado com seu próprio guia de contribuição.