Screenpipe: gravação de tela vira agente. E a privacidade?

O Screenpipe fez seu Launch HN no dia 23 de julho, dentro do batch S26 da Y Combinator, e passou dos 82 pontos com a discussão rachada ao meio.

A proposta é desconfortável de tão simples: um daemon que grava como você trabalha — tela, áudio, cliques, troca de aplicativo — e transforma esses procedimentos em agentes que repetem seu fluxo. Não é um agente que você programa com prompt. É um agente que aprende assistindo você.

Neste post a gente destrincha a arquitetura (que é tecnicamente interessante de verdade), o paradigma de "agente por demonstração", a treta da licença que saiu de MIT pra source-available, e as duas perguntas que a comunidade fez e que todo dev deveria fazer: isso passa num compliance corporativo? E o que impede um agente comprometido de ler meses do seu histórico?

TL;DR

O que é: gravador local de atividade do computador (tela + áudio + eventos do SO) que indexa tudo num banco pesquisável e roda agentes em cima desse contexto.
Stack: Rust + Tauri, MLX/ONNX pra inferência local, SQLite com FTS5, MP4 e Markdown no disco, API REST em localhost:3030. Transcrição de áudio local com Whisper Large-V3-Turbo ou Parakeet (Deepgram como opção cloud).
Custo/Acesso: source-available (era MIT). Uso pessoal gratuito; comercial exige licença paga (planos de US$ 25 a US$ 150/seat/mês).
Link útil: github.com/screenpipe/screenpipe (20,5 mil stars) e a thread do Launch HN.

Como o Screenpipe funciona por baixo do capô

A primeira reação de qualquer dev é: "gravar a tela 24/7 vai derreter minha máquina e encher meu SSD". A arquitetura existe exatamente pra evitar isso.

Em vez de gravar vídeo contínuo, o Screenpipe é orientado a eventos do sistema operacional: troca de app, clique, pausa de digitação, scroll, idle. Quando um evento indica que algo mudou na tela, ele captura um screenshot pareado com a árvore de acessibilidade do SO — que já entrega o texto estruturado da janela, sem precisar "ler" pixels. OCR só entra como último recurso, quando não há dado estruturado disponível.

O áudio segue a mesma filosofia local-first: transcrição no próprio hardware com Parakeet ou Whisper, com identificação de quem falou. Tudo desagua em armazenamento local: SQLite com busca full-text, arquivos MP4 e Markdown. Nada sobe pra cloud por default.

Em cima disso, uma API REST na porta 3030 expõe esse histórico pra agentes — com autenticação, suporte a MCP e a "skills". Os agentes em si (o projeto chama de pipes) são definidos em arquivos Markdown e rodam agendados: resumo de reunião, recap diário, atualização de CRM quando você visita um perfil no LinkedIn.

Sobre consumo de máquina, aqui vale separar o que é claim do que é verificado. O README fala em 5–10% de CPU, 0,5–3 GB de RAM e ~20 GB de storage por mês. O fundador, Louis (louis030195 no HN), afirma na thread que o time faz benchmark "num laptop de US$ 200" e que o modelo próprio de redação de PII — que roda local via MLX no Mac e DirectML no Windows — consome menos de 1% de CPU e menos de 400 MB de RAM. São números do fundador, não auditados por terceiros. Plausíveis pra um modelo pequeno de classificação? Sim. Verificados? Não.

Agente por demonstração, não por prompt

Aqui está a parte que realmente importa pra quem constrói produto com IA — e o motivo de o Screenpipe ser mais interessante que "mais um gravador de tela".

O jeito dominante de dar contexto pra um agente hoje é declarativo: você escreve um prompt, conecta um MCP server, define tools. Funciona, mas o contexto é estático — o agente sabe o que a integração expõe, não o que você faz de verdade. O próprio fundador diz na thread que o MCP "parecia estático demais" pra resolver o problema que ele queria atacar: o micro-gerenciamento constante que agente de tool-calling exige.

A aposta do Screenpipe é inverter a direção: em vez de você descrever o procedimento pro agente, o agente observa o procedimento acontecendo. Toda vez que você atualiza o CRM depois de uma call, organiza notas no Obsidian, preenche a mesma planilha — isso vira dado. O agente aprendido por demonstração repete o fluxo com o seu contexto real, não com uma descrição idealizada dele.

Isso não é ideia nova — programming by demonstration é literatura antiga de IHC, e RPA tenta algo parecido há uma década com resultado frágil. A diferença é que agora existe um modelo de linguagem no meio, capaz de generalizar o procedimento em vez de reproduzir cliques cegos. Se funciona bem em produção, ainda é pergunta aberta. Mas como paradigma, é a antítese direta do "engenharia de contexto é escrever prompt bonito": aqui o contexto é minerado do trabalho real.

Pra quem já sofreu montando contexto de agente na mão — decidindo o que entra no prompt, o que vira tool, o que vai pro RAG — a provocação é boa: e se o pipeline de contexto fosse o seu próprio dia de trabalho, indexado?

A treta: de MIT pra source-available

Agora, o lado que fez a comunidade torcer o nariz.

O Screenpipe nasceu MIT. Em algum momento, trocou pra uma licença própria ("Screenpipe Commercial License"): uso pessoal, educacional, sem fins lucrativos e de pesquisa continuam livres; uso comercial paga. As versões antigas permanecem MIT — licença não é retroativa —, mas o repositório de 20,5 mil stars que muita gente estrelou como open source hoje é source-available. São coisas diferentes, e a comunidade FOSS não deixou passar.

Na thread, o usuário lrvick fez a crítica clássica (e correta) do modelo: quem tem mais tempo que dinheiro vai fazer self-host e talvez contribuir; quem tem mais dinheiro que tempo põe o cartão de crédito — e o meio-termo que a licença tenta capturar acaba convidando clones "lavados por IA" sem licença nenhuma. A sugestão dele: AGPL, que mantém a comunidade dentro e força empresa a pagar ou abrir.

A resposta do fundador foi rara de se ver em Launch HN: "you're right that we should have set this license early on instead of switching" — reconheceu o erro de ter trocado no meio do caminho e sinalizou abertura pra rever. Não resolve o problema de quem construiu em cima esperando MIT, mas é mais honesto que o padrão "pivotamos para melhor servir a comunidade".

A lição pra quem constrói: licença é decisão de arquitetura. Trocar depois que a comunidade chegou custa confiança — e confiança é exatamente o ativo que um produto que grava sua tela menos pode se dar ao luxo de queimar.

▪ Clã Beer and Code

Não só acompanhe as novidades — domine. Engenharia de IA na prática, ao vivo, toda semana, na maior comunidade do Brasil.

Entrar no Clã

"Nenhuma corporação sã permite isso"

O comentário mais duro da thread veio do usuário siva7: nenhuma empresa sensata permitiria esse software nas máquinas dos funcionários, citando o EU AI Act e leis de privacidade do trabalhador.

E ele tem um ponto. O EU AI Act trata sistemas de monitoramento de trabalhadores como área sensível, e legislações como a LGPD aqui no Brasil exigem base legal pra tratar dado pessoal — e uma gravação contínua da tela captura dado pessoal de terceiros o tempo todo: o e-mail do cliente aberto no navegador, a conversa do Slack, o prontuário, o extrato. Não é só a sua privacidade em jogo; é a de todo mundo que aparece na sua tela.

A resposta do fundador aponta pros mitigadores: no plano enterprise tudo roda on-premise, a empresa participa da configuração ("we usually collaborate with the company to allow screenpipe"), e existe um modo que desativa screenshots e captura só a árvore de acessibilidade — texto estruturado, sem imagem. Somam-se os controles de produto: filtro por app, janela e URL, respeito a aba anônima, agenda de gravação e o modelo de redação de PII rodando local.

São mitigadores reais, mas repare no que eles são: configuração, não garantia. O default de um gravador é gravar. Numa empresa, a distância entre "instalou com filtro certo" e "instalou e esqueceu" é uma auditoria de compliance de diferença. Se você pretende levar algo assim pra dentro de um time, o desenho da política vem antes do download — quais apps entram, quem acessa o índice, qual a retenção. O fundador, aliás, declara na thread que a visão é o oposto de retenção curta: "Screenpipe would record forever so that you have infinite memory". Memória infinita é a feature. E é exatamente ela que o jurídico vai querer discutir.

E se um agente comprometido ler todo o seu histórico?

A pergunta de segurança mais afiada da thread veio do usuário rahulladumor: depois de meses de uso, o SQLite local vira um dossiê completo da sua vida digital. O que impede um agente malicioso — ou comprometido — de consultar tudo via API na porta 3030?

A resposta oficial: além de autenticação na API, existe um sistema de permissões declarado no próprio header Markdown de cada pipe — dá pra restringir qual janela de tempo o agente pode consultar e qual modalidade (só texto de acessibilidade, só transcrição de áudio, etc.). Um agente de resumo diário não precisa enxergar além das últimas 24 horas; um agente de CRM não precisa de áudio.

É o desenho certo — least privilege aplicado a memória de agente. Mas a superfície de ataque continua sendo o produto inteiro. A gente já mostrou como um repositório aparentemente limpo pode injetar instruções maliciosas num agente de código; agora imagine o mesmo vetor com um agente que tem acesso de leitura ao histórico da sua tela. Prompt injection num pipe do Screenpipe não vaza um repositório — vaza o que você viu, digitou e falou. A resposta da indústria pra credenciais foi tirar o segredo do alcance do agente, como no 1Password for Claude; com memória de tela, o "segredo" é o próprio dado, e a única defesa é escopo agressivo por padrão.

A pergunta que fica pra qualquer arquitetura dessas: as permissões são enforçadas pelo runtime ou são convenção no Markdown? A thread não detalha o mecanismo de enforcement — e essa é exatamente a diferença entre guardrail e post-it.

O que é claim do fundador vs o que é verificado

Separando com honestidade, porque post de lançamento mistura as duas coisas:

Verificado (código público, observável):

Código-fonte público, stack Rust/Tauri, SQLite + FTS5, API em localhost:3030, pipes em Markdown — está no repositório.
Arquitetura local-first por default, confirmada por múltiplos usuários na thread.
Licença atual source-available; versões antigas seguem MIT.
20,5 mil stars, ~2 mil forks.

Claim do fundador (sem auditoria independente):

Modelo de PII com <1% CPU e <400 MB RAM, "melhor que Google, Microsoft e OpenAI" em redação de dado sensível.
Benchmark fluido "em laptop de US$ 200".
Consumo geral de 5–10% de CPU e ~20 GB/mês de storage.
Eficácia real do enforcement de permissões por timeframe/modalidade.

Nada disso é acusação — é o desconto padrão que se aplica a qualquer Launch HN. Mas num produto cuja premissa é "me deixa gravar tudo", a régua de prova tem que ser mais alta que a média.

FAQ rápido

Roda 100% local ou manda dado pra cloud? Local por default: SQLite, MP4 e Markdown no seu disco, inferência via MLX/ONNX. Existem opções cloud opt-in (transcrição via Deepgram, sync criptografado). A superfície de rede local é a API na porta 3030 — trate como trata qualquer serviço com dado sensível em localhost.

Posso usar de graça? Uso pessoal, educacional e de pesquisa, sim. Uso comercial exige a licença paga (a partir de US$ 25/mês). Versões anteriores à troca de licença continuam MIT — mas sem as features novas.

Quanto pesa na máquina? O projeto declara 5–10% de CPU, 0,5–3 GB de RAM e ~20 GB de storage/mês, com mínimo recomendado de 8 GB de RAM. São números do próprio time — se for adotar, meça no seu hardware antes de concluir qualquer coisa.

Funciona no Linux? Sim — macOS (Apple Silicon e Intel), Windows 10/11 e Linux, segundo o repositório. A qualidade da árvore de acessibilidade varia por SO, o que afeta quanto o sistema precisa recorrer a OCR.

Conclusão

O Screenpipe é as duas coisas ao mesmo tempo: genial e pesadelo de privacidade em potencial. A engenharia é séria — captura por evento, acessibilidade antes de OCR, inferência local, permissão por escopo. E o paradigma de agente aprendido por demonstração ataca o problema certo: contexto de agente hoje é artesanal, e o seu trabalho real é a melhor fonte de contexto que existe.

Mas a mesma propriedade que torna o produto poderoso — memória infinita da sua tela — é a que faz jurídico, segurança e a comunidade FOSS levantarem a mão. Gravador que vira dossiê é questão de quando, não de se, alguém vai tentar explorar.

O próximo capítulo dessa categoria vai ser decidido menos por benchmark e mais por enforcement: quem provar que o agente só enxerga o que precisa, quando precisa, leva. Enquanto isso, se você quer entender o outro lado dessa moeda — como limitar o que um agente pode tocar —, vale reler como blindar seu setup de agente de código contra repositório malicioso.