Claude-Mem no GitHub: o que tem no repositório oficial do projeto

Quem digita "claude-mem github" na busca quase nunca quer review de terceiro: quer bater o olho no projeto na fonte antes de deixar uma ferramenta gravar o que o agente anda fazendo na máquina

E isso é saudável, viu? 😀

O Claude-Mem é uma camada de memória persistente para agentes de IA, e o código está publicado no repositório oficial no GitHub, na conta thedotmack, mantida por Alex Newman (@thedotmack)

Ou seja: dá pra auditar licença, arquitetura declarada e ritmo de releases sem instalar absolutamente nada

Bora abrir o repositório junto?

O que o repositório diz que o Claude-Mem faz

Pré-inscrição Formação Claude Code

Domine o Claude Code do básico ao avançado

Você vai aprender a criar sistemas completos com Claude Code, sem precisar ser programador. Inscreva-se para ter acesso a um desconto de lançamento e bônus especiais!

Quero minha vaga

A descrição oficial do projeto é curta e vai direto ao ponto: "Persistent Context Across Sessions for Every Agent"

Traduzindo o que está declarado ali: o Claude-Mem captura tudo que o agente faz durante a sessão, comprime esse material com IA e injeta o contexto relevante nas sessões seguintes

A analogia mais honesta é a de um caderno de bordo do agente: em vez de você repetir o mesmo briefing toda vez que abre uma sessão nova, o histórico volta mastigado

E tem um detalhe que muita gente não percebe de cara: o escopo declarado no repositório não é só Claude Code

A lista de agentes citada inclui Claude Code, OpenClaw, Codex, Gemini, Hermes, Copilot, OpenCode e outros

Se você já teve o hábito de abrir o repositório do OpenClaw antes de instalar, o exercício aqui é exatamente o mesmo: ler o que o projeto promete na própria página antes de dar acesso a ele

Licença e a fronteira entre aberto e comercial:

Esse é o bloco que interessa pra quem trabalha em empresa e precisa responder "posso usar isso em projeto comercial?" sem levar bronca do jurídico depois

O código do Claude-Mem é publicado sob Apache License 2.0

E o repositório não deixa a coisa solta: existem dois arquivos que delimitam o escopo de licenciamento e a fronteira entre o que é aberto e o que é comercial, docs/license.md e docs/ip-boundary.md

Tem ainda um detalhe de organização: o diretório ragtime/ dentro do repositório declara a licença dele em arquivo separado, o ragtime/LICENSE, sob a mesma Apache License 2.0 do resto do código

E se você for atrás da documentação, atenção: ela mora em outro repositório e com OUTRA licença

O claude-mem-docs sai sob MIT, enquanto o código do claude-mem é Apache 2.0

Parece detalhe chato, mas é justamente o tipo de coisa que trava revisão de compliance lá na frente: licença de doc não é licença de código, e tratar os dois como a mesma coisa dá dor de cabeça

As três branches de release: main, core-dev e community-edge

Aqui mora a resposta pra uma dúvida clássica de quem compara o repositório com o pacote publicado: por que o npm às vezes parece atrás do que você vê no GitHub?

Porque o projeto trabalha com três branches de release, e só uma delas vai pro npm

O fluxo de promoção está definido na documentação e é bem simples de guardar: trabalho novo entra por PR em core-dev ou em community-edge, a community-edge promove para core-dev e a core-dev promove para main

Ou seja, a main é o fim da esteira, não o começo

O pacote está publicado no registro do npm como claude-mem, e a versão mais recente lá é a 13.15.2

Arquitetura declarada: onde ficam os dados e o que roda local

"Mas esse negócio manda meus dados pra onde?"

Essa é a pergunta certa, e o projeto documenta a resposta

O armazenamento é local e dividido em duas camadas: SQLite em ~/.claude-mem/claude-mem.db pros dados estruturados e ChromaDB em ~/.claude-mem/chroma/ pros embeddings semânticos

A busca é híbrida, combinando as duas coisas: SQLite FTS5 pra busca por palavra-chave e Chroma pro retrieval semântico

As duas rodando localmente

E o que orquestra tudo isso é um worker service em background, um servidor HTTP em http://localhost:37777, executado pelo runtime Bun

No mesmo endereço vive um viewer web, um visualizador local pra você acompanhar as memórias em tempo real

Achei mto massa esse detalhe: em vez de confiar na fé de que a memória está funcionando, tu abre o navegador e olha

Como instalar a partir do que o repositório recomenda:

Os caminhos documentados são dois, e vale escolher um só

1. Instale pelo instalador oficial, que é o caminho mais curto:

npx claude-mem install

O erro comum deste passo: rodar npm install -g claude-mem achando que resolve

A documentação avisa direto que isso instala apenas o SDK/biblioteca, e não registra os hooks nem sobe o worker service

Aí você fica com o pacote na máquina e sem memória nenhuma funcionando, se pergunta o que houve, e a resposta é que nada foi ligado

2. Ou, se preferir ir pelo marketplace de plugins, faça dentro do Claude Code:

/plugin marketplace add thedotmack/claude-mem
/plugin install claude-mem

O manifesto usado nesse caminho está versionado no próprio repositório, em .agents/plugins/marketplace.json, então dá pra conferir antes de rodar

3. Verifique se o worker realmente subiu, batendo no endpoint de health:

curl http://localhost:37777/api/health

A resposta esperada é {"status":"ok"}

O erro comum deste passo: pular a verificação

Sem essa checagem, você só vai descobrir que o worker não está de pé quando a memória não voltar na próxima sessão, e nessa hora fica difícil saber se o problema foi a instalação ou o uso

O que dá para conferir no repositório antes de adotar

Essa é a parte que transforma "dei uma olhada no GitHub" em decisão de verdade

Cada item abaixo é um critério, não curiosidade:

• Ritmo de manutenção: o repositório mantém histórico de versões no CHANGELOG.md na branch main e na página /releases. É onde você vê se o projeto está vivo ou parado
• Problemas em aberto: a aba de issues é pública, em https://github.com/thedotmack/claude-mem/issues. Dá pra ver que tipo de bug aparece, que tipo de dúvida se repete e como o mantenedor responde
• Instruções do projeto pro próprio agente: tem um CLAUDE.md na raiz da main. Ler esse arquivo é uma forma rápida de entender como o projeto espera ser trabalhado por dentro, mesma lógica de quando você avalia se dá pra ter skills reaproveitadas entre repositórios ou se cada projeto precisa da sua
• Alcance da comunidade: o README tem traduções versionadas dentro do repositório, na pasta docs/i18n, com README.ja.md, README.es.md, README.de.md, README.fr.md, README.tr.md e README.zh.md
• Documentação separada: a doc oficial fica em docs.claude-mem.ai, servida por um repositório próprio, o claude-mem-docs

Juntando tudo: em uma sentada de meia hora você já sabe se o projeto tem licença clara, arquitetura documentada, manutenção recente e canal público de suporte

Vale abrir o repositório antes de instalar?

Vale, e por um motivo bem pragmático

O repositório entrega os quatro sinais que costumam decidir a adoção de uma ferramenta que toca no teu ambiente: licença explícita (Apache 2.0), arquitetura documentada (armazenamento local em SQLite e ChromaDB, worker em http://localhost:37777), histórico de versões e uma aba de issues pública

Esse é o mínimo pra decidir com alguma segurança, e é bem mais do que muita ferramenta hypada entrega

O próximo passo eu faria nessa ordem: abrir o repositório e a documentação em docs.claude-mem.ai, conferir a última release, ler o docs/ip-boundary.md se o uso for comercial, e SÓ ENTÃO rodar a instalação pelo caminho recomendado

Curioso pra ver como isso se comporta no teu fluxo do dia a dia? faça o teste e me conta depois

até o próximo post! =)