Why local-first still matters for developer tools in 2026

Everything ships with a cloud in 2026. Your IDE syncs to a backend. Your terminal emulator ships telemetry. Your note app is a thin shell over somebody else's Postgres. The default posture for a new developer tool is "your data lives on our servers and we promise we are nice about it".

Claude Recall does not do that. It reads the most sensitive stream of data on a developer's machine (the full transcript of every conversation they have had with an AI, including the code in those conversations) and it keeps all of it on the user's disk. No account. No server. No telemetry. Not now, not planned.

This post is the case for why that posture is not nostalgia. It is the only responsible shape for this class of tool.

The dead-man clause

The first question to ask about any developer tool you install: if the vendor goes out of business tomorrow, do I still have my data, and can I still use the tool?

For most cloud-backed products, the answer is no. The data lives in their Postgres; your export script either does not exist or produces a format nobody else reads. The tool is a front end to an API that will 404 the moment the company runs out of money. Every contract you sign with a SaaS vendor is implicitly betting on their continued existence.

Local-first inverts that. The data is on your disk in a documented format. The binary runs without reaching any server. When the vendor disappears, the user loses future updates. They do not lose their data, and they do not lose the tool's function on the data they already have. This is the dead-man clause, and it is the only credible answer to the "why should I trust you" question for a tool that indexes your history.

Recall's data format is boring on purpose: a SQLite database, a mirror directory of plain-text markdown files, and the original JSONLs which we never touched in the first place. If Recall stops existing, the SQLite database still opens in any SQLite client, the markdown mirror opens in any editor, and the JSONLs remain exactly what Anthropic shipped. Nothing of yours is trapped.

The three-layer durability pattern

Every write operation in Recall (alias, tag, note, pin, add to collection) goes through three writes:

1. The SQLite row is updated in place.
2. A history row is appended to the same database, capturing the previous value.
3. The plain-text mirror on disk is regenerated.

The source JSONLs at ~/.claude/projects/ are strictly read-only. We never modify them. This is the hardest invariant in the codebase: if a piece of code looks like it might write to those files, it is wrong and it gets rejected in review.

The effect is that you cannot lose data. Delete a tag by accident? History row has it. Corrupt the SQLite? The plain-text mirror has it. Lose the whole Recall install? The JSONLs are still there, and re-indexing rebuilds everything.

The network posture

The daemon binds 127.0.0.1 only. Never 0.0.0.0. Never a LAN IP. Never a public interface.

This one line in the server config is doing more work than a hundred-page privacy policy:

server.listen({ host: '127.0.0.1', port: dynamicPort });

It means the service is not reachable from anywhere except the machine it runs on, full stop. No "forgot to configure the firewall" failure mode. No "misconfigured reverse proxy exposed it to the internet" incident. No attack surface for the browser at clauderecall.com to reach across origins into your local daemon and exfiltrate sessions, because the browser's cross-origin policy plus the loopback bind is enough to stop it cold.

There is no outbound network either. The daemon does not call home. It does not check for updates. It does not ship anonymous usage stats. The only planned outbound call is license validation in v0.6, and even that will be a single endpoint, infrequent, with a hard offline fallback.

Auto-redaction at ingest

The JSONLs sometimes contain secrets. You pasted an API key into a prompt, you showed Claude an .env file, you leaked a JWT while debugging. That data is real and it is on your disk whether or not Recall exists.

At ingest, Recall runs a redaction pass. Known secret patterns (AWS keys, GitHub tokens, Stripe keys, JWTs with typical headers, long hex blobs that parse as private keys) are replaced with a placeholder before the text lands in SQLite or the plain-text mirror. The original JSONL is untouched, because we do not write to it. But the searchable index and the exportable artifacts are scrubbed.

The redaction patterns are documented in the security doc, and the list is conservative on purpose: we redact things we are confident are secrets, and leave ambiguous cases alone rather than corrupt legitimate text.

The compliance story

"Does your tool store our customer data?" is a question every security review asks. The honest answer that most cloud tools have to give is "yes, encrypted at rest, SOC 2, here is a 40-page attestation". The honest answer that Recall gives is "no, the tool cannot see your data; it runs entirely on the developer's machine and makes no outbound calls".

That answer is shorter, cheaper to produce, and vastly easier for a security team to verify. They can watch the process list. They can sniff the loopback. They can read the source. The absence of a server is a feature that sells itself once you are talking to someone who has to sign the review.

Takeaway

Local-first is not about nostalgia for the 90s desktop app. It is the only posture that gives a straight answer to three questions that every developer tool should have to answer: who has my data, what happens when you disappear, and can I prove you are not doing something I did not agree to.

Recall ships as a single npm install -g recall away. Everything in this post is enforced in code, not in policy. Read the security doc and the data doc for the exact implementation, and head to /install when you want to try it.