knack ← all docs

Docs · last updated

Knack packs don't phone home

Why no installed pack ever calls a Knack server, what data we don't collect, and how to verify the claim yourself in under a minute.

Most “AI tools” are SaaS. They wrap a model behind a server, log every call, and use what you typed to train next month’s product. Knack is the opposite shape. A knack pack is files on your disk. The pack content runs inside your Claude Code, against your Anthropic API key, with no Knack code in the loop.

This page explains what that means concretely, what we don’t collect, and where to look if you want to verify the claim yourself.

The promise

When you install a knack pack:

  • No installed pack makes a network request. Not the install script. Not the skills. Not the agents. Not the slash commands. The contents are markdown and shell scripts that Claude Code reads locally.
  • We don’t see your Claude Code sessions. We can’t. Your prompts and the model’s outputs travel between your machine and Anthropic’s API. Knack isn’t a hop in that path.
  • We don’t see what you do with a skill. Skills run inside your Claude Code, and Claude Code reads them locally. There’s no event stream we receive.
  • No licence-server check. The licence key in ~/.claude/knack/<pack-id>.licence is honour-system. Claude Code can read it; we never see it again after the moment of purchase.
  • No update telemetry. When you install a new version of a pack, the installer doesn’t tell us. We learn install counts only from the download endpoint logs (one HTTP request when you click the link in your purchase email).

How to verify

Open the pack zip you downloaded. Then:

# macOS / Linux
unzip /path/to/pack.zip -d /tmp/pack-check
grep -ril 'curl\|wget\|fetch\|http://\|https://' /tmp/pack-check

You’ll see hits in the README and in markdown skill bodies, where URLs appear as documentation links. You should see no hits inside install.sh, install.ps1, or any executable file. If you do, that’s a regression and we want to hear about it: support@knack.run.

# Windows
Expand-Archive -Path C:\path\to\pack.zip -DestinationPath C:\temp\pack-check
Select-String -Path C:\temp\pack-check\*.* -Pattern 'curl|wget|fetch|http' -Recurse

The honest exception: the marketing site

The site you’re reading this on (knack.run) uses Cloudflare Web Analytics. That’s a single edge-injected counter that records aggregate page views, referrer, and country, with no cookies, no IP retention, and no personal identifiers. There is no cookie banner because there are no cookies to consent to.

That’s the only analytics on the site. No Google Analytics, no Mixpanel, no Hotjar, no session-recording, no marketing pixels.

Full detail in the privacy policy. The distinction matters: an installed pack runs on your machine and is silent; the marketing site that sells you the pack is a normal website with normal aggregate analytics.

What about Polar and Resend

Polar handles payments. They see your purchase: name, email, country (for tax), card processor’s response. They are the Merchant of Record, which means they handle VAT and chargebacks; in exchange, they hold the payment record. Their privacy policy covers this.

Resend handles email. When you buy, you get a delivery email and (later) update emails when a pack you own ships a new version. Resend stores your email address and the messages we send. You can unsubscribe from update emails at any time; the delivery email is contractual (you bought a pack, we tell you where to download it).

Neither Polar nor Resend has anything to do with the pack itself once it’s on your disk. They’re checkout and inbox; the pack is its own thing.

Why we did it this way

Phone-home telemetry, even the harmless kind, creates two problems for solo operators. First, the analytics dataset is itself a liability: it has to be secured, deleted on request, and explained in a privacy policy. Second, it changes the trust shape of the product. A pack that calls our servers is a product we can update, downgrade, or break remotely. A pack that’s just files is yours.

The trade-off is that we know less than a SaaS would. We don’t know which skills get used most. We don’t know which prompts work best in practice. We learn from what buyers email us instead, which is slower but is the only signal that tells us the truth.

If that trade-off ever stops being right, we’ll change the policy in public, on this page, with a date stamp. Anything else would be the kind of behaviour that makes the SaaS model so tiring in the first place.