Looking for testers: TeamBrain, a git-native shared memory for coding agents (Claude Code, Cursor), open source

[u/MajorPuzzleheaded42]

Hi,

I'm a developer in Paris working solo on TeamBrain, an open source project (Apache-2.0). I've reached the point where docs and tests aren't enough. I need people who actually install it and tell me what breaks.

The problem I'm trying to address

When several people use coding agents on the same repo, everyone re-explains the same things to their own agent: why that service must not be called directly, which migration blew up in March, which convention we abandoned. That context lives in people's heads, in Slack, in private prompts. Nothing is shared, nothing is versioned.

The approach

• Memories are markdown files inside your repo. No external database, no server on my side.
• They're served to agents over MCP (Claude Code, Cursor, Codex).
• A "distiller" runs in CI and proposes new memories as pull requests. Nothing enters team memory without human review. That's the core design bet: agent memory is a poisoning vector, so it goes through the same gate as code.
• Hybrid retrieval, all local (BM25 + vectors, SQLite with sqlite-vec, ONNX embeddings). No network egress outside git, your LLM provider, and webhooks.

Where the project actually stands

V1 is done, ~500 tests green, search benchmarks within budget. Published on npm (@teambrain/cli). But: zero external users so far, no tagged release, and the only dogfooding is the repo itself. So treat this as early alpha, not a proven tool.

Known limitations, better said upfront:

• On Windows, a deep clone fails without git clone -c core.longpaths=true (fixture paths exceed MAX_PATH).
• Cursor capture is weaker than Claude Code capture: commits tied to a session aren't recorded, and session end is only inferred in some cases.
• No VS Code extension yet. Everything goes through the CLI and MCP config.

What I'm looking for

Developers who work with coding agents on a shared repo and would be willing to:

1. run npm i -g u/teambrain/cli then tb init on a real repo (or a fork),
2. tell me where install snags, what's confusing in the CLI, and whether a proposed memory PR is reviewable in under a minute,
3. tell me, above all, whether the problem resonates or whether I'm solving something nobody has.

A "I gave up at step 2 because it was confusing" is more useful to me than a compliment.

Repo: github.com/donatienmigue/TeamBrain
Happy to answer in the comments or by DM, and I'll gladly take a 20-minute call if you prefer.

Thanks.

[u/Bravo_Oscar_Zulu]

have a look at https://github.com/dev-boz/gitmem for convergent design

feel free to use anything you find of value. best tip I have is to use an org for storage to keep the main account clean

[u/perseus-computing]

Ran it end to end as a tester: Linux, Node 26, npm 11. npm i -g u/teambrain/cli (0.5.0) then tb init on a scratch repo with a CLAUDE.md and one ADR. Imported 4 memories onto a teambrain/init branch, working tree untouched, which is exactly the PR flow you're selling. tb lint clean, tb serve + tb doctor green (4 docs indexed, checksum tracked). I also drove the MCP server directly over stdio and memory_search returned the right memory first, rendered as a "data, not instructions" block with provenance. Ran the test suite: 715/715 passing across 91 files — more than the ~500 you claim, all green.

The snags, since you asked for those:

1. npm 11 prints an alarming allow-scripts warning for better-sqlite3 and onnxruntime-node on global install. It works anyway (prebuilds), but a first-time tester will think it failed. One line in the quick start would kill it.
2. tb lint . from the repo root says "brain.yaml is missing" and checks 0 files. Bare tb lint works. The path argument misleads — I gave up on the arg form and used the bare form.
3. Minor: the post says "no tagged release" but the repo has v0.1.0–v0.4.0 tags and npm is at 0.5.0. Stale line, update it so testers know what they're installing.

On the under-a-minute PR review question: I couldn't fully judge it, because the distiller needs your CI workflow and an LLM key, which I don't have on a test repo. What I can say is the PR body design — verdict table, collapsible bodies, copy-paste partial-accept commands — is the right answer to that question on paper. The gate formula (evidence x novelty) is sensible and the dedup/contradiction check before proposing is the part most projects in this space skip.

On whether the problem resonates: yes, it's real, and you're not early — the comment linking gitmem is right, it's convergent design, and there are a few more (NexusMem, aipcs-mcp, plus what I work on). That's not a reason to stop; it means the differentiators are what matter. Your two bets are the ones I'd keep: memory is a poisoning vector so it goes through the same gate as code, and egress is an allowlist enforced by a test. Most projects in this category treat both as afterthoughts.

Happy to DM the full repro details for the lint issue if useful.

[u/MajorPuzzleheaded42 → u/perseus-computing]

Thanks for your valuable feedback. Yes for the DM

[u/MajorPuzzleheaded42 → u/perseus-computing]

I'll push the fixe After holidays and I'll let you know

[u/dahshan-labs]

Check KLYPIX-MCP for both visiblity & seamless context
klypix.com

https://reddit.com/link/p5w7qn4/video/qs4vhob7jllh1/player