Last updated 18 August 2026
Privacy notice
What Emendant sends, what it never sends, and what the feed origin can see.
Emendant is a command line tool you install and run on your own machine. There is no account, no sign-in and no service that receives your source code. This notice describes every place data exists, and every network request the tool can make: the feed download, the registry request that proves a fix, and the excerpt an assisted fix sends to a provider you name. A scan makes none of them.
Who operates Emendant
Emendant is operated by Soham Jain, an individual established in the United Kingdom, who is the data controller for the processing described here. Contact: privacy@emendant.com.
There is no telemetry
Nothing about you, your machine or your repository is ever sent to the operator of Emendant. There is no usage counter, no error reporting, no crash reporter, no licence check and no identifier of any kind, and a scan makes no network request at all. This is a property of the code rather than a setting: the only thing Emendant itself can request is a feed file, at one of four fixed paths, carrying nothing about the repository it is scanning.
Two other requests exist, and both go somewhere you chose rather than to us: proving a fix asks your own package manager's registry for a release, and an assisted fix sends a bounded excerpt to a model provider you name on the command line. Each has its own section below, and neither reaches anything the operator of Emendant runs.
The feed download
Emendant ships with a copy of the change feed, so it works with no network access. A newer feed is fetched only when you ask for it, either by running emendant feed update or by turning automatic refresh on, which is off until you turn it on once.
A refresh requests one of exactly four paths from feed.emendant.com:
timestamp.jsonroots/<sequence>.jsonsnapshots/<id>/manifest.jsonsnapshots/<id>/feed/<path>
There is no query string, no custom header, no request body and no cookie. Emendant downloads one whole snapshot, identical for every user, rather than the entries for the packages you depend on. That is deliberate: a per-package request would write your dependency list into an access log one line at a time, and this design has nowhere to put it.
Who serves it, and what they can see
| Operator | Cloudflare, Inc. R2 object storage behind a custom domain, on the operator's Cloudflare account. Cloudflare serves the files from its global network, so a request may be answered outside the United Kingdom |
|---|---|
| What is requested | one of the four paths above |
| What is observable anyway | your IP address, the time, a TLS fingerprint and a user agent, as with any HTTPS request |
| Request logging | R2 access logging and Logpush are not enabled for this bucket. Cloudflare's own analytics for the hostname are aggregate rather than per request, and are retained for Cloudflare's standard period for the account plan |
| Who can read it | the operator named above, and Cloudflare under its own terms |
An access log, if one were enabled, could show that some address fetched some snapshot at some time. It could not show what that machine depends on, because no repository fact appears in anything Emendant constructs. Where this processing happens, the lawful basis is legitimate interests: serving and securing a file download that somebody asked for.
Your choices
| Make no request at all | automatic refresh is off until you turn it on, and --offline makes no request in any mode |
|---|---|
| Fetch from somewhere else | set EMENDANT_FEED_ORIGIN to your own mirror. It is safe to point elsewhere: an origin decides what bytes arrive and never whether they are accepted, because signatures are checked against a trust root inside the installed package |
| Delete what was fetched | remove the cache directory below. Nothing else on your machine records that a fetch happened |
What Emendant writes to your machine
None of this leaves your machine. It is listed because a tool should say what it writes.
| Feed cache | ~/Library/Caches/emendant/feed, $XDG_CACHE_HOME/emendant/feed or the platform equivalent: verified snapshots, the accepted sequence floor and the last refresh time. The newest three snapshots are kept |
|---|---|
| User configuration | $XDG_CONFIG_HOME/emendant/config.json or the platform equivalent: one answer, whether automatic refresh is allowed |
| Project configuration | emendant.json in your repository, written by your project rather than by Emendant |
The cache holds published feed files, which are public. It holds no scan result, no finding, no repository path and no dependency list.
Assisted fixes, which you have to switch on
A few changes have no mechanical remedy. For those, and only when you name a model provider with--model-provider, Emendant sends the matched block, about twenty lines of context and the file's import block from your machine directly to that provider. Nothing else about the repository goes with it, and Emendant never receives or stores any of it. That provider's own terms and privacy policy govern what it does with the excerpt. Without an explicit provider those findings are reported unfixed and nothing is sent anywhere.
Proving a fix asks your registry for a version
A patch for an upgrade you have not made yet describes your code after that upgrade, so Emendant cannot prove it without the new release on disk. To get it, emendant fixruns your own package manager (npm, pnpm or yarn) in a scratch tree that holds this repository's manifests, lockfiles and package manager configuration, and none of your source code.
| Who receives it | whichever registry your package manager is configured to use, which is npm's public registry unless your project says otherwise. If that is a private registry inside your organisation, the request goes there and not to npm |
|---|---|
| What they receive | the ordinary install request your own npm install would make: the packages named in your manifests and lockfiles, and the credentials in your .npmrc that reach a private registry |
| What they do not receive | your source code, which is never in that tree. The install scripts that come back are run afterwards with the network taken away and none of your credentials |
| What Emendant receives | nothing. This request is between your machine and your registry, and no part of it reaches the operator of Emendant |
| How to avoid it | --dry-run previews patches without proving them, and --no-verify skips the step. Both grade the patch structurally checked instead, which the report says plainly |
This is the same request your own upgrade would make, a day earlier. It is written down here because a notice that lists only the requests we invented would be describing something narrower than what running the tool actually does.
Installing the package
Installing Emendant is a request to the npm registry, operated by npm, Inc. (GitHub). What npm logs is governed by npm's own privacy policy, and the operator of Emendant receives nothing from it beyond the aggregate download counts npm publishes for every package. The package has no install script.
This website
emendant.com is static, hosted on Cloudflare. It sets no cookies, runs no analytics and embeds no third party scripts. Your colour theme choice is kept in your browser's local storage and is never sent anywhere. Cloudflare processes request metadata to serve the site, as above.
If you contact us
An email you send is kept for as long as it takes to deal with it and to keep a record of security reports, and is not used for anything else. Reports of a vulnerability are kept indefinitely as part of the security record, because a fix has to stay explicable.
Your rights
Under UK data protection law you can ask what personal data is held about you, ask for it to be corrected or erased, and object to processing. Write to privacy@emendant.com. In practice there is very little to ask about: no account exists, and nothing identifies you to Emendant. If you are not satisfied with the response you can complain to the Information Commissioner's Office at ico.org.uk.
Changes to this notice
This notice is dated at the top. A change is published here with a new date, and a change that materially affects what leaves your machine is also stated in the release notes for the version that makes it.