Privacy

aidokit ships zero telemetry by design. Nothing about your project, your prompts, your edits, or your machine ever leaves your machine because of aidokit. This page exists to make that promise auditable rather than asking you to trust it.

What aidokit never does #

The scaffolder, the CLI commands, the watchdog hooks, the adapter emission, the conformance harness, the doctor / verify commands — none of these:

• Make HTTP requests to maintainer-controlled servers. The CLI never phones home, ever, including on init, on errors, on update checks, or anywhere else.
• Aggregate usage statistics of any kind — anonymous or otherwise.
• Read or inspect your prompts sent to Claude Code or any other AI coding CLI. Your model traffic is between you and your vendor; aidokit doesn't sit in that path.
• Upload diagnostics automatically. If you want to share a bug report, you copy and paste — there is no "send error" button.
• Embed analytics scripts in any emitted artefact, including CLAUDE.md, the docs skeleton, or hook scripts.

What aidokit does — explicitly, transparently #

• Reads your project files during init, doctor, verify, and sync — entirely locally, never transmitted.
• Writes files into your project root at paths it tells you about before writing (init confirms the count; sync --dry-run previews every file).
• Invokes your local CLI (claude mcp add, bd ..., etc.) when you asked for it. These invocations are visible in your shell.
• Reads environment variables it documents, such as AIDOKIT_METRICS, CLAUDE_PROJECT_DIR, and standard NodeJS variables.

The MetricsLog — local, opt-in, user-owned #

aidokit ships a MetricsLog for users who want to quantify AI-assisted-workflow signal on their own project. It is local-first by design:

• Off unless you turn it on. Set AIDOKIT_METRICS=1 in your shell (or your project's .envrc) to opt in. The variable is the only way events get written.
• Local file only. Events go to agent-artifacts/metrics/events.jsonl inside your own project. They are JSON lines you can inspect with cat, jq, or your editor.
• No upload step exists. There is no aidokit metrics upload. The only way data leaves your machine is if you manually attach the file to an email, a GitHub issue, or a PR.
• Inspect with: aidokit metrics summary [--since 7d].
• Share with: aidokit metrics export --output share.json (then attach to feedback@aidokit.dev if you want maintainers to see it).

Why not telemetry? #

Because the project's audience — developers using AI coding tools on real projects, often containing client code or proprietary IP — should not have to trust a third party with that signal. The trade-off is maintainers see less, slower, and only when users choose. We think that's the right trade-off; it's also a hard constraint, not a feature flag.

If aidokit ever needs visibility into how users use it, we will:

1. Ask explicitly, publicly, with rationale.
2. Make it strictly opt-in, never opt-out.
3. Document exactly what is collected and how it's stored.
4. Ship the change in a versioned release with a BREAKING_NOTICE entry.

If you ever find a network call in aidokit that this page doesn't document, treat it as a bug and open an issue. Provenance for trust requires an audit surface.

What you might still want to know #

• @aidokit/* npm packages ship via npm.com. npm itself logs installs (npm and pnpm both make GET requests to the registry). This is npm's policy, not aidokit's — but it is real network activity, and you should know about it.
• MCP servers you install (Context7, Beads MCP, Playwright, …) have their own privacy stories. aidokit does not control them. Read their docs.
• bd (Beads) is a separate CLI we recommend but don't ship. Its data layer is local SQLite; the project does not phone home as of this writing, but verify with their docs.
• Your AI coding CLI (Claude Code, Codex, Copilot CLI) has its own telemetry posture. Configure it as you would normally; aidokit does not change those defaults.

Audit / verification #

You can verify aidokit's posture yourself:

• Source inspection. All packages are Apache-2.0 OSS at github.com/aidokit-project/aidokit. Look for fetch(, http, https, axios, node:net, node:https — the only allowed uses are during npm install (the registry) and inside MCP servers you explicitly opted into.
• Process tracing. Run aidokit init --dry-run under strace (Linux) or dtruss (macOS) and observe the system calls — no outbound network sockets are opened.
• Capability declarations (Strict tier). Each adapter declares every network host it might contact. aidokit verify enforces the declaration matches the emitted hooks.

Reporting a privacy issue #

If you find a privacy gap or believe aidokit is doing something this page does not document:

1. Open a public issue tagged privacy — non-security issues belong in the open.
2. For potential security implications (e.g. a leaked credential path), email security@aidokit.dev first; coordinated disclosure is appreciated.

See also #

• Hall of Pain — the failure modes aidokit is designed to prevent (no privacy gaps, by construction)
• Security model — broader capability and watchdog story
• Conformance levels — what each tier emits