Bigarrow: Como um Agente de IA Aponta para o Botão Certo na Sua Tela

Toda vez que um agente de IA precisa de você para apertar um botão, acontece a mesma cena: ele escreve please click Allow in the dialog dentro de um terminal que você fechou faz meia hora. Fica travado esperando. Você só descobre quando volta pra mesa.

O bigarrow resolve esse problema de um jeito deliberadamente burro: deixa o agente desenhar uma seta gigante por cima de qualquer janela, com uma plaquinha de texto, apontando pro botão que precisa ser clicado.

O fato

Franz Enzenhofer publicou em 8 de outubro de 2026 o bigarrow, uma ferramenta de linha de comando para macOS, mais um Skill para Claude Code e Codex. É MIT, e um agente usa a ferramenta para desenhar uma seta grande com uma plaquinha de texto sobre qualquer app, para que um humano saiba exatamente qual botão clicar. Ela nunca clica nem digita por conta própria.

O repositório passou de 600 estrelas na primeira semana. Instala com brew install franzenzenhofer/tap/bigarrow, e um comando a mais ensina o skill ao Claude Code e ao Codex.

Como funciona por baixo

A primeira coisa estranha do bigarrow: ele desenha por cima de tudo, mas o desenho em si não precisa de nenhuma permissão do macOS. Isso é raro em ferramentas que mexem com a tela. Vale entender por quê.

A janela transparente que fica em cima, mas nunca em foco

No macOS, estar na frente e estar em foco são coisas diferentes. Uma janela em foco é a que recebe seus toques de teclado. Uma janela na frente é a que o olho enxerga primeiro na pilha de janelas.

O bigarrow cria uma janela transparente, do tamanho da tela, posicionada num nível que o macOS chama de screen saver level. Esse nível fica acima de janelas normais, de diálogos modais e até de apps em tela cheia, mas é marcado como não-ativável. O sistema nunca vai mandar eventos de teclado pra ele.

A analogia que carrega a mecânica: pense num plástico transparente que você cola na tela do laptop, desenha uma seta de caneta e deixa lá. O plástico está na frente de tudo, mas se você digitar no teclado, o texto vai pro Word que está por baixo, não pro plástico. Onde a analogia quebra: o plástico bloquearia o clique no botão por baixo. A janela do bigarrow deixa o clique passar.

Click-through, exceto onde não é

A seta tem duas partes visuais: a haste (o traço) e a plaquinha (o texto). Em todo o resto da janela, o clique atravessa como se nada estivesse ali. Dentro da haste e da plaquinha, o clique é capturado, mas só pra uma coisa: remover a seta. É o jeito de o humano dizer ok, entendi, sai da frente.

Esse detalhe de arquitetura importa porque elimina uma classe inteira de bugs: a seta não compete com a interface. Você clica no botão que ela aponta, o clique vai pro app por baixo, nenhum foco troca de lugar.

Como ela encontra o alvo

O comando aceita várias formas de dizer onde apontar:

• --at X,Y: coordenada global na tela
• --rect X,Y,W,H: um retângulo
• --mouse: onde o cursor está
• --window App:título: uma janela específica
• --element Label --app App: um controle pelo rótulo acessível

A opção --element é a mais interessante, porque usa a API de Accessibility do macOS, a mesma que o VoiceOver usa. Cada controle de interface no sistema expõe um rótulo, um papel (botão, campo de texto, radiobutton) e uma posição. O bigarrow pergunta ao macOS onde está o controle chamado Allow dentro do System Settings? e recebe coordenadas de volta.

É aqui que entra a diferença de permissões. Desenhar não precisa de nada. Mas para descobrir onde está o botão Allow, o bigarrow precisa que o app que o invocou (Terminal, iTerm2, Ghostty, VS Code, Claude) tenha permissão de Accessibility. O macOS concede essa permissão ao processo pai, nunca ao bigarrow em si. Se faltar, o comando sai com código 4 e diz qual painel de ajustes abrir.

Por que isso é um Skill, e não um MCP

O bigarrow se instala como Agent Skill, um formato que a Anthropic publicou como padrão aberto. Skills são pastas de expertise que o agente carrega sob demanda. Cada skill tem um SKILL.md com YAML frontmatter contendo nome e descrição, mais um corpo em markdown com instruções, opcionalmente ao lado de arquivos de referência e scripts executáveis. O agente só vê o nome e a descrição (cerca de 100 tokens) até uma solicitação combinar, aí lê o corpo, e toca em arquivos adicionais só quando as instruções apontam para eles.

Essa carga em camadas é o que o bigarrow explora com cuidado: o README afirma que a descrição do skill custa 182 tokens o tempo todo, as instruções principais (1.528 tokens) só carregam quando o agente decide apontar, e as referências de parâmetros (mais 1.118) só quando ele precisa escolher um visual específico.

Em prática, o skill ensina ao agente quando apontar (permissões, 2FA, pagamentos, trechos pra colar), como escrever uma frase inteira na plaquinha, e quando parar depois que você agir. O binário faz o desenho, o skill faz o julgamento.

O que termina uma seta

Toda seta expira sozinha. É uma das decisões de design mais importantes:

• Limite de tempo: point dura 8 segundos, start dura 300 segundos por padrão
• O processo do agente morreu: uma seta termina quando o processo do agente que a desenhou sai (CLAUDE_PID, ou BIGARROW_OWNER_PID)
• O humano respondeu: bigarrow stop --hook funciona como UserPromptSubmit hook do Claude Code e limpa a seta daquela sessão
• Clique na seta: dim visual sob o cursor avisa que vai sumir

Nada de setas órfãs flutuando pela tela porque o agente travou.

O que isso significa na prática

Um comando real, direto do README:

bigarrow point --element "Allow" --app "System Settings" \
 --text "Franz, click Allow: Ghostty may control your Mac"

Isso: traz System Settings pra frente, acha o botão Allow pela API de Accessibility, desenha uma seta apontando pra ele, com uma plaquinha dizendo exatamente o que o clique faz. Oito segundos depois, some.

Um detalhe que mostra o cuidado do design: quando você usa –app com nome de app seguido de dois pontos e título de janela ou aba, a ferramenta primeiro traz essa aba do Chrome ou Safari pra frente, porque apontar pra uma janela escondida atrás do seu terminal é inútil.

Outro truque: {{value}} dentro do texto vira um botão de copiar. Comando típico pra pedir um PIN:

bigarrow start --element "PIN code" --role textfield \
 --app "Google Chrome:Acme sign-in" \
 --text "Franz, copy & paste the PIN {{482913}} here"

Essa combinação, agente que acha o campo + plaquinha com botão de copiar, é a parte que de fato ensina um padrão novo: quando o agente precisa de um input humano, ele não só pede, ele prepara o terreno pro humano agir em um clique.

No StartAtende, meu agente de suporte no WhatsApp, essa mesma lógica aparece em outro meio: o agente faz quase tudo, mas em certos pontos (confirmação de pagamento, decisão sobre reembolso) ele precisa que um humano decida. A diferença é que no WhatsApp o canal é texto, então o custo cognitivo de “ir até o lugar certo e fazer a coisa certa” vira uma frase. Numa interface gráfica desktop, esse mesmo pedido vira procurar visualmente um botão num menu que você nem sabe que existe. A seta corta isso.

Onde quebra

A ferramenta é macOS only, e nem toda versão. Precisa de macOS 14 ou mais, Swift 6, Xcode 16 pra compilar.

A detecção por --element depende de Accessibility estar habilitado pro app pai. Se você rodar o Claude Code no Terminal e nunca tiver dado essa permissão, o comando falha com código 4.

Páginas web dentro do Chrome são um caso específico: segundo o README, em Chrome, –element só funciona com ajuda, exigindo –force-renderer-accessibility ou VoiceOver ligado, porque o Chrome ignora a requisição padrão de accessibility. Em Electron apps a detecção funciona normal. A barra do próprio Chrome (botões de navegação, abas) sempre funciona.

No macOS 26, títulos de janela ficaram ocultos para apps externos, então --window App:título precisa de permissão de Screen Recording nessa versão. Mais um lugar onde a Apple apertou e a ferramenta teve que se adaptar.

Um limite menos óbvio: a seta aponta pro que a árvore de accessibility declara. Se um app tem a árvore mal configurada (controles sem rótulo, elementos custom desenhados em canvas), o agente não acha. O fallback é apontar por coordenada fixa, o que quebra quando o layout muda.

Nos livros que escrevi, entre eles a série IA na Prática, uma coisa que sempre tento deixar clara é essa: ferramentas que dependem da árvore de accessibility herdam toda a dívida técnica de UI de quem construiu o app alvo. O bigarrow é tão bom quanto o rótulo do botão que ele tenta achar.

Custo de CPU segundo o próprio projeto: 1,4% num runner de CI. Pequeno, mas não zero, porque a animação de pulsar é constante enquanto a seta existe.

O que não dá pra afirmar ainda

Não testei pessoalmente. As afirmações sobre comportamento (nunca rouba foco, nunca clica, nunca captura tela) vêm do README e dos 104 testes automatizados que o projeto declara ter. O autor mostra transcrições e vídeos, mas eu não validei em máquina minha.

Também não dá pra afirmar como isso envelhece. O macOS tem histórico de apertar APIs de accessibility a cada versão, e parte da promessa do bigarrow depende dessas APIs continuarem como estão. Já teve um reaperto na transição pra macOS 26 (títulos de janela), nada impede outro.

Sobre segurança: o próprio FAQ reconhece que um agente que já roda shell no seu computador pode fazer coisas muito piores que uma seta, então o vetor de ataque adicional é pequeno. Ainda assim, nunca vi uma análise independente dessa superfície. Vale ter em mente antes de instalar.

Como testar isso você mesmo

Caminho mínimo, uns 10 minutos:

1. Instale com brew install franzenzenhofer/tap/bigarrow
2. Rode bigarrow doctor pra ver o que falta de permissão
3. Dê Accessibility pro Terminal (ou pro app onde roda seu agente) no painel que o doctor indicar
4. Teste direto, sem agente: bigarrow point --mouse --text "aqui". A seta aparece onde seu cursor está
5. Teste com alvo real: abra o Finder e rode bigarrow point --element "Search" --app Finder --text "campo de busca"
6. Se tudo funcionar, instale o skill com bigarrow install-skill e peça ao Claude Code: me ensina a ativar o modo escuro usando o bigarrow

Esse último passo é o teste real. O agente precisa decidir sozinho que a tarefa pede apontar, escolher os elementos certos, montar os comandos com texto que faça sentido. Se o skill foi bem escrito, ele faz. Se não, você aprende rápido onde o padrão de Skills tem limite.