Privacy Policy

This policy explains what data the Archcore project processes across three surfaces: the Archcore plugin (for Claude Code, Cursor, and other AI coding agents), the Archcore CLI, and the archcore.ai website. Archcore is designed to be local-first: your code and documentation never leave your machine unless you explicitly send it somewhere.

Plugin & CLI

• Fully local. The plugin and CLI run on your machine. All Archcore documents live in the .archcore/ directory inside your Git repository.
• No telemetry about your work. Neither the plugin nor the CLI reports what you do with Archcore: no document contents, no document titles, no file paths, no repository or branch names, no commands you ran, no usage tracking, and no crash reports. The plugin sends nothing at all. The CLI reports two things and nothing else — that it was installed, and that it updated itself — both described below, and both carrying only version and platform fields.
• No accounts, no servers. Archcore requires no sign-up, API key, or backend service to function. The MCP server runs locally as a child process.
• AI host providers. When you use Archcore inside an AI coding agent (Claude Code, Cursor, etc.), that host may send excerpts of your Archcore documents to its model provider as part of your prompts. Those transfers are governed by the host's own privacy policy, not by Archcore.
• Installation. The install scripts at archcore.ai/install.sh and archcore.ai/install.ps1 download release binaries from GitHub Releases. Standard web request metadata (IP, user-agent) may be logged by GitHub and our CDN during download; we do not retain it ourselves.
• Install analytics. The install scripts send us one event when an install finishes or fails, so we can tell how many people are actually installing Archcore. It contains the version installed, your operating system and CPU architecture, whether this was a first install or a repeat one, whether the run looked like a CI environment, and, if it failed, which of the eight steps it stopped at. It never contains an error message, a file path, a directory name, a user name, a hostname, or anything about your repository.
• The CLI keeps itself up to date. From version 0.8.0 the installed binary can replace itself with a newer release without being asked. The check runs in the background of archcore mcp, the local server your coding agent starts, at most once every 24 hours per machine. It installs only a release published by this project, verified against its SHA-256 checksum and run once to prove it starts before anything is replaced. Your running process is never restarted or interrupted; a new version takes effect the next time the binary starts.
• There is no switch that turns updating off. Unattended update has no opt-out variable and no setting in .archcore/settings.json, because replacing a binary is machine-wide and a per-project file cannot govern it. If a machine must not update itself, install the binary into a directory its user cannot write — a root-owned location is the supported answer, and every attempt then stops before it downloads anything. Builds you compile yourself, forks, and CI runners never self-update at all.
• Update analytics. The binary sends us one event per update attempt, so we can tell whether a release actually reaches machines: one when it replaced itself, one when a step failed, and one when a background attempt stopped because nothing newer existed or because the install directory was not writable. Each contains the version it came from and the version it went to, your operating system and CPU architecture, whether the run looked like a CI environment, whether you typed the command or the background check ran it, and, if it failed, which of the five steps it stopped at. It never contains an error message, a file path, a directory name, a user name, a hostname, or anything about your repository.
• The install identifier. Those events are keyed to a random value generated at install time and kept in ~/.local/state/archcore/install-id, so reinstalling on the same machine is counted once rather than as a new person. The installers and the CLI read and write that one file, so an install and every later update on a machine count as one person rather than several. It is random, not derived from your hardware, your account, or your network, and deleting that file gives you a new one. Events reach the same PostHog project as the website analytics, through edge.archcore.ai. CLI builds released before that change use ph.archcore.ai until they update.
• Opting out of it. Set DO_NOT_TRACK=1 or ARCHCORE_TELEMETRY_OPTOUT=1 in the environment. Set before the installer runs, it covers the install event; set for your shell or for your coding agent, it covers the update events too. Nothing is sent and no identifier file is written, so opting out leaves no trace on your disk. The installer and a typed archcore update each print a one-line notice when they do send an event, so you are never told about this only here. These two variables govern analytics only: they do not stop the CLI from updating itself.
• Download counts. We also read the public download totals of our own release files from GitHub's API and chart them. Those are per-file totals only. GitHub does not tell us, and we cannot infer, who downloaded anything.

archcore.ai website

• Analytics. We use PostHog across archcore.ai and docs.archcore.ai to understand aggregate traffic (pages viewed, referrer, country, approximate device type) and how people use the pages: links clicked, how far down a page you read, which commands you copy, which questions you open, and what you type into the docs search box. We do not record your screen or session, and we do not collect form contents or anything that identifies you personally. Analytics respect Do Not Track and can be blocked with any standard content blocker. No analytics run in development builds.
• Email list. If you submit your email via the subscribe form, we store it solely to send product updates. You can unsubscribe at any time.
• Cookies. We use a small number of first-party cookies for analytics and to remember your language preference. No third-party advertising or tracking cookies.

What we do not do

• We do not read or upload your source code.
• We do not read or upload the contents of your .archcore/ directory.
• We do not sell data to third parties.
• We do not use your data to train AI models.

Your rights

You can request access to, correction of, or deletion of any personal data we hold (currently only possible if you have subscribed to our email list) by emailing us at archcore-ai@proton.me.

Changes to this policy

We may update this policy as the product evolves. Material changes will be reflected in the “Last updated” date at the top of this page.

Contact

Questions about this policy? archcore-ai@proton.me