Problem
"Nothing leaves your machine" is the entire premise of this project. Today it's backed by readable code and a promise in the docs — nothing enforces it. A dependency upgrade could introduce a telemetry call and every test would still pass.
The core claim of the project deserves a test, not just a paragraph.
What to build
A CI job that runs the full suite with outbound network access blocked, and fails if anything tries to reach out.
Acceptance criteria
Approaches worth considering
- Socket-level: monkeypatch
socket.socket in a fixture to raise on connect. Simple, in-process, catches anything using Python sockets — which is everything here.
- Network namespace: run the job with no route out. Stronger, catches subprocesses and native extensions too, but more CI plumbing.
- A proxy that logs and denies, asserting the log is empty. Gives the best failure message.
The socket patch is probably the right first step — cheap, and catches the realistic regression. A stricter namespace-level job could follow.
Notes
Worth testing the negative case too: a deliberately-connecting test should fail under this harness. A guard that can't fail is worse than no guard, because it's actively misleading.
Pointers
docs/guide/privacy.md — the claim being enforced
.github/workflows/ci.yml — the integration job already handles model pre-warming with a cache
Problem
"Nothing leaves your machine" is the entire premise of this project. Today it's backed by readable code and a promise in the docs — nothing enforces it. A dependency upgrade could introduce a telemetry call and every test would still pass.
The core claim of the project deserves a test, not just a paragraph.
What to build
A CI job that runs the full suite with outbound network access blocked, and fails if anything tries to reach out.
Acceptance criteria
store_memory,search_memory,recall_memory, and the CLI equivalentsmaindocs/guide/privacy.md— "verified by CI" is a much stronger claim than "we promise", and it's the kind of thing that decides adoptionApproaches worth considering
socket.socketin a fixture to raise on connect. Simple, in-process, catches anything using Python sockets — which is everything here.The socket patch is probably the right first step — cheap, and catches the realistic regression. A stricter namespace-level job could follow.
Notes
Worth testing the negative case too: a deliberately-connecting test should fail under this harness. A guard that can't fail is worse than no guard, because it's actively misleading.
Pointers
docs/guide/privacy.md— the claim being enforced.github/workflows/ci.yml— the integration job already handles model pre-warming with a cache