Last updated: September 2026 | View online | Open-source notices
This Privacy Policy describes how Helm Dev, Inc. ("we", "us"), a California corporation, collects, uses, and protects information when you use our desktop application, Helm ("the Software"). Helm is a local desktop application: almost everything it does happens on your machine, and the sections below are mostly about the few exceptions.
Helm is beta software and is under active development. This policy will change as the product does.
This is the most important thing to understand about privacy and Helm.
Helm does not supply an AI model. You choose the provider — for example Anthropic, OpenAI, Google, or a model running locally on your own machine — and you connect your own API key, subscription, or local installation. When Helm sends a prompt, your code, or your project context to a model, it goes from your machine to the provider you selected, under the agreement between you and that provider.
That means:
Two different mechanisms, one destination. For most work, Helm runs the provider's own command-line tool on your machine and that tool talks to the provider directly — Helm is not part of the conversation. For some features — multi-model code review, and image generation — Helm makes the request itself, from your machine, using the API key you supplied. In both cases the content goes straight from your computer to the provider you chose, and in neither case does it pass through our servers or reach us. The difference is which program on your machine opens the connection, not where your data ends up.
There is one exception, described next.
So you can evaluate Helm before connecting a provider of your own, Helm may offer a small, capped amount of trial capacity. When — and only when — that lane is used:
trial.helm.dev), which forwards it to an
AI provider using our key and returns the response.If you would prefer that no prompt ever passes through our infrastructure, connect your own cloud provider key before using Helm's AI features.
When Helm encounters an error, we may collect the following. This only happens if you have left crash reporting on; see Section 9.
Crash reports help us identify and fix bugs. They do NOT contain your project code, file contents, or personal documents. An error message can name a file or a path when the error originates in your project's files — so treat "no file contents" as exactly that, and not as a promise that no file name ever appears.
When you approve a diagnostic report (Section 4.4), what is recorded here is a note that a
report of that kind was submitted — labelled with its error type from a fixed set (for example
rust_panic) — alongside the crash-report fields listed above. The report's own message text is
not sent to Sentry; the report itself goes only to us, as described in Section 4.4.
When you have usage analytics switched on (see Section 9), Helm collects anonymized usage analytics to help us understand how the product is used and where to focus improvements. Specifically, we collect:
A single anonymous identifier (randomly generated, not linked to your identity) is used for analytics. This ID is stored locally on your device.
This data helps us improve Helm. It NEVER includes:
Helm derives a machine fingerprint from your hardware. It is used to bind a license to a device and to enforce per-machine trial caps. It is not used for tracking.
Activating a paid license, and re-checking it, contacts our licensing provider. When you activate a license, when Helm re-checks it at startup (it re-checks when the last successful check is more than a day old), and when you ask it to check now, Helm sends your license key and your machine fingerprint to the licensing provider that issues and validates Helm licenses on our behalf. Deactivating a device sends the identifier of that device's activation so the seat can be released, and authenticates that request with your license key so the provider can confirm the seat is yours to release. On each of those paths Helm sends no project contents, no file names, and no prompts.
Between those checks your license is verified on your machine, against a signed certificate stored locally, so Helm keeps working while you are offline.
Our licensing provider holds your license key, the devices activated against it, and when those checks happened, so that the per-device limit and refunds can be enforced. It handles that data for us, under our instructions, and not for its own purposes.
The trial lane (Section 3) sends a salted hash of the fingerprint — never the raw value — so per-machine caps can be enforced without transmitting the hardware identifier itself.
Depending on where you are, a device identifier of this kind may count as personal data under local law even though it is not tied to your name.
When an error occurs during AutoPilot execution, Helm may ask if you'd like to send a diagnostic report. These reports are only sent with your explicit approval.
An approved report contains the error type, the error message, the code location the error was reported from, the Helm version, your operating system, what you were doing at the time, a short description of the app's state, and — if you write one — the description you type into the report box. Helm sends that description to us verbatim; it does not filter it. If you paste source code, a file path, a project name, or an email address into that box, that text reaches our servers. Everything in Section 5 below is subject to this exception: it describes what Helm sends on its own, not what you choose to include in a report you approve.
The error message and the location are captured by Helm, not written by you, and either can contain a file path or other project detail when a crash originates in your project's files. When Helm asks for your approval it shows you the complete report, in full — every field it will transmit, with nothing truncated or summarised — so that what you consent to is what is actually sent. Your description is the only part added afterwards, and you type it yourself.
Two paths send a report without showing it to you again first, and both exist only because you turned automatic sending on:
A report you declined is not sent. If Helm shows you a report and you choose "Save Locally Only" — or dismiss the window without sending — Helm marks that refusal on the saved report itself. Once the mark is there, turning automatic sending on afterwards does not release it: neither path above will transmit a report marked declined, and Helm offers no way to un-decline one. The report itself stays on your machine and you can still read or export it.
Recording that mark is the one step that can fail — for example if the file has already been moved or removed, or the disk refuses the change. Helm does not fail silently here: if it cannot record your refusal it tells you on screen at the time, and says what that means. Nothing is transmitted at that moment. The residual risk is only that a report whose refusal could not be recorded still looks unanswered to the catch-up batch described above, so it could be sent later if you switch automatic sending on. If you see that message and the report matters to you, delete the report and the question goes away.
You can turn automatic sending off at any time, and reports are always saved locally whether or not they are sent.
This path is not covered by the Settings switch. If you turn crash reporting and analytics off (Section 9) and then click "Send Report" on a diagnostic, the report is still sent. We treat your explicit click as the more specific instruction — the switch tells us what to collect on our own initiative, and this is not that. If you would rather send nothing at all, decline the report: a declined report is never transmitted by any path.
Separately from the crash reports above, when a Helm test scenario fails you may be offered a one-click "Send error report". This is never automatic — nothing is sent unless you click it, and nothing is sent at all if error reporting is switched off in Settings.
That bundle is a different payload from the crash report described above. It contains the failure message, a slice of Helm's own recent internal activity log, your operating system and architecture, the Helm version, and — when Helm is run from a source checkout — the Git revision of that checkout. The format also has room for buffered analytics and diagnostic breadcrumbs; Helm does not currently put any in, and those fields go out empty. The bundle is assembled from Helm's own diagnostics rather than from your project's files.
Before the bundle is saved, the failure message and the activity-log entries — the parts that can
carry text from your machine — are passed through the same secret-redaction used elsewhere in Helm:
API keys, tokens, private keys and connection-string passwords are replaced, and your home directory
is rewritten as ~. That is redaction, not anonymisation: the rest of a path survives it, so your
project's folder name or a file name can still appear. The bundle is not shown to you field by field
before it is sent, so unlike the crash report above, you are approving the ACTION rather than a
payload you have read.
Helm can check whether a newer version is available. Automatic update checking is switched off in the current build, so no update request is made. When it is enabled in a future release, a check will contact our update service, and — like any web request — will necessarily reveal your IP address and the version you are running. It sends nothing else.
That is a statement about update checks, and only about update checks. Helm does make other requests on its own initiative, including some on every launch, and Section 4.7 describes them.
Two features work by asking a public service a question. Neither sends your code, neither uses an account or key, and neither is telemetry — but both mean a detail about your project leaves your machine, so they belong here.
True of every look-up in this section, before anything else is said about it. Each one is an ordinary web request from your computer to somebody else's service, so — exactly as with the update check in Section 4.5 — it necessarily reveals your IP address, and the fact that you made the request when you did, to whoever answers it. That is a consequence of asking at all rather than something Helm attaches, and no bullet below is an exception. Where a bullet says what a look-up "sends", it is describing the project-specific data in the request, on top of this.
Dependency licence checks. When Helm checks the licences of the packages your project depends on, it looks each one up on that ecosystem's public registry. The project-specific data differs by ecosystem, and in each case it is only what that look-up needs:
registry.npmjs.org) and crates.io (crates.io) — the only project-specific
request data is the package name. The request asks for the package's whole record, and
which version you depend on is selected from the reply, on your own computer, after it
arrives. crates.io additionally receives a fixed identifier for this checker,
Helm/1.0 (license-check), which names Helm and says nothing about you.pypi.org) — the only project-specific request data is the package name, and the
version when Helm has a specific one to ask about; otherwise the package name alone.None of the three sends your code, your project name, or your file paths. Bear in mind that a list of dependencies says something about what a private project is built with — and that the registry can associate that list with the IP address it came from.
Custom-domain checks. If you connect a custom domain, Helm checks whether your DNS records
have propagated by querying public DNS-over-HTTPS resolvers (Cloudflare first, then Google
as a cross-check). The project-specific data it sends is the domain name you entered and which
kind of DNS record is being checked (A, AAAA, CNAME or TXT — an ALIAS/ANAME record
is checked by asking for A, because that is all the public internet can see of one). Both are
facts about a domain that is, by design, about to be public anyway. Each request also carries
Helm as its user agent, which names the program asking and says nothing about you. The value
you expect the record to hold is not sent — the answer is compared on your own computer.
These run as part of features you invoke, and they are not governed by the Settings switch in Section 9, which covers crash reporting and analytics.
Section 4.5 covers a check that is currently switched off, and Section 4.6 covers look-ups that happen because you invoked a feature. This section covers the rest — requests Helm makes without being asked, including several on every launch, and the handful it makes to other people's services for information.
True of every request in this section, before anything else is said about it. Each one is an ordinary web request from your computer to somebody else's service — ours included — so, exactly as with the update check in Section 4.5, it necessarily reveals your IP address, and the fact that you made the request when you did, to whoever answers it. That is a consequence of asking at all rather than something Helm attaches. Where a description below says what a request "sends", it means the project-specific or account-specific data in the request, on top of this. Two of these requests carry such data, and each says so.
Every time Helm starts, it fetches three small configuration files from helm.dev in the
background — whether or not you do anything, and with no setting that turns them off:
It also fetches the current text of these legal documents from helm.dev when the acceptance
screen opens — which is before you have accepted anything — so that what you are asked to accept
is the current version rather than the copy that shipped inside the app.
Each of the four is a plain request for a fixed public file. The project-specific request data is none: no identifier, no licence key, no project detail, no account. What we can learn from them is what any web server learns — that a machine at your IP address asked for a file at a particular time — which, on the launch fetches, tells us that somebody started Helm.
Helm also reaches services that are not ours, on its own initiative, to read information rather than to hand anything over:
A public source repository, currently GitHub. So it can offer you an accurate list of a provider's current models, Helm fetches that provider's published model configuration from the public repository it lives in (today, one file in the Gemini CLI's GitHub repository). This runs during Helm's start-up model discovery when its cached list is more than six hours old, and again whenever models are refreshed. The project-specific request data is none — it is a fixed URL, no account and no credential are involved, and Helm is reading a public file exactly as a browser would.
Your AI provider's status page. While Helm is running it checks the status page published by the provider you have selected — Anthropic's, OpenAI's or Google's, depending — so it can tell you when a failure is that provider's outage rather than a problem on your machine. It checks about once every five minutes, more often while AutoPilot is working, and it starts when Helm starts, using the provider you saved as your default; switching provider inside the app moves the check with you. If separate projects use separate providers, the page checked is the one Helm is currently set to, which need not be the provider of whichever project you have open. The project-specific request data is none, and the page is public; what the request discloses beyond the IP address and timing above is implicit in who receives it — that a machine at your address is using that provider. (A locally-run model has no status page: while one is what Helm is set to use, it makes no such request at all.)
Services used by a feature you ran. Three requests belong to specific features rather than to Helm's own housekeeping, and two of them do send something:
artificialanalysis.ai) is fetched only if you have entered an
Artificial Analysis API key in Settings, and only when quality scores are refreshed. That
request sends the API key you entered, because that is what the service requires. With no key
entered, the request is never made.Helm/1.0 (design-extraction).picsum.photos, addressed only by the pixel dimensions
wanted, and other file types are downloaded from a public address the AI provider's own web
search returns. The project-specific request data is none in either case.Dependency-advisory services, when you run an app-assurance check and only after you have said yes on the in-app consent screen. To tell you whether the packages your project depends on carry known vulnerabilities, Helm asks public advisory services about them. The first (currently deps.dev) receives the ecosystem, the name of each dependency you depend on directly, including private and scoped names, and the version your lockfile pins, and, in a second request, the identifiers of the advisories it returned. The others (currently OSV and FIRST.org) receive only advisory or CVE identifiers, never a package name or version, and are not contacted when there is nothing to look up. Requests are capped per check. Because a private dependency name can reveal confidential project or vendor information, Helm sends these names only after your consent, and you should decline the check for a project whose dependency names you cannot disclose. The consent screen names the current services and exactly what is sent; if we add or change a service, that screen and Section 8 change with it.
None of the requests in this section is governed by the Settings switch in Section 9, which covers crash reporting and analytics. Unlike the look-ups in Section 4.6, most of these are not tied to anything you invoked — they are how the shipped app keeps itself current, and the honest summary is that running Helm means these requests happen.
Read this as a statement about CONTENT, not about contact. Helm does contact our own servers on its own initiative — on every launch, and again when the acceptance screen opens, before you have accepted anything. Section 4.7 says which requests those are and what they retrieve; none of them carries anything from the list below, which is the point of keeping the two sections apart.
To be unambiguous — Helm never sends the following to our servers on its own:
The exception is a diagnostic report you choose to send us — a crash report you approve (Section 4.4) or a scenario failure bundle you click to send (Section 4.4a). Those are the only paths by which any of the above can reach us, and each only happens because you chose to send it: the description you type is transmitted verbatim, and the captured error message can itself contain a file path or other project detail. This list describes what Helm sends by itself — it is not a promise about content you deliberately put into an approved report.
AI conversation content goes to the AI provider you selected, not to us — with the single exception of the trial lane described in Section 3. Content sent to your chosen provider is governed by that provider's privacy policy.
Helm stores data locally on your machine at ~/.vibe/:
data.db — a database containing your projects, tasks, settings, and session history.vibe/ directories within your project foldersHelm also reads and writes files inside the projects you open with it — that is its core function.
This data never leaves your machine unless you explicitly use a feature that transmits it (for example an AI call to the provider you configured, or a deployment to a hosting provider you connected) — with one exception that runs on its own: if you have activated a license, Helm re-checks it with our licensing provider as described in Section 4.3, which sends your license key and machine fingerprint from this database.
To do its job, Helm may hold credentials you provide — AI provider API keys, and tokens for services you connect such as GitHub or a hosting or database provider. These are stored on your machine and are used to talk to those services on your behalf. They are not transmitted to us. Anyone with access to your machine and your operating-system keychain may be able to reach them.
One credential Helm reads but did not create. To detect whether you already have a Claude subscription — so it can avoid asking you to set up something you have — Helm reads the login item that Claude Code stores in your operating-system keychain. Your system may show an authorisation prompt when it does. This is a local read only: the credential is never transmitted to us or to anyone else, and declining the prompt only means Helm asks you to connect a provider itself.
Helm may interact with the following third parties:
Sentry (sentry.io) — crash reporting (see Section 4.1)
PostHog (posthog.com) — usage analytics (see Section 4.2)
Our licensing provider — issues and validates Helm licenses on our behalf. It receives your license key and your machine fingerprint when you activate a license, when Helm re-checks it, and when a device is released, and it holds that data for us under our instructions (see Section 4.3)
Our own trial edge service (trial.helm.dev, operated on Cloudflare) — the limited trial
lane (see Section 3)
Our own servers (helm.dev) — the configuration files Helm fetches on every launch, and the
current text of these legal documents when the acceptance screen opens. These carry no project
or account data (see Section 4.7)
The AI provider you select — AI interactions are governed by that provider's privacy policy (see Section 2)
Services you connect — for example GitHub, or the hosting and database providers you use for deployment, each under their own terms
A public source repository, currently GitHub, that you did NOT connect — Helm fetches a provider's published model list from a public repository on its own initiative, so it can offer you current models. This is a different thing from the row above, where you connect an account, and it is described in Section 4.7
Your AI provider's status page — Anthropic's, OpenAI's or Google's, depending on the provider Helm is set to use, checked while Helm is running so it can distinguish an outage from a local fault; none is checked while that provider is a locally-run model (see Section 4.7)
Services a feature you ran reaches on your behalf — Artificial Analysis
(artificialanalysis.ai), which receives the API key you entered for it when quality scores are
refreshed; picsum.photos and other public sources of sample files during a smoke test; and
the website whose address you give to branding extraction (see Section 4.7)
App Store Connect and Google Play, when you ask Helm to submit an app for you. Helm uploads your build and its store metadata to your own developer account, using the credentials you provided. Your agreement with Apple or Google governs that submission, and it remains your submission — see our Terms of Service.
Public dependency-advisory services (currently deps.dev, OSV and FIRST.org), which receive dependency names and pinned versions (deps.dev) or advisory and CVE identifiers only (the others), solely when you run an app-assurance check after consenting in the app (see Section 4.7).
Cloudflare and Resend, for the helm.dev waitlist. Cloudflare stores the waitlist for us, and Resend sends the waitlist emails (see the helm.dev Website and Waitlist section).
Sentry, PostHog and our licensing provider process data in the United States.
A full list of the third-party open-source software distributed inside Helm, and the licence each is used under, is published at helm.dev/legal/notices. That list is generated from the shipped build rather than maintained by hand; it is provided on a best-efforts basis and is not part of this policy.
We ask before we collect. The first time you launch Helm, it shows you what crash reporting and usage analytics do and lets you decide. Declining takes one click, changes nothing about how Helm works, and we do not ask again.
The starting position depends on which build you are running, and Helm tells you which:
If you are in the EEA or the United Kingdom, crash reporting and usage analytics stay off until you turn them on, whichever build you are running, so that your consent comes before anything is sent.
Either way you can change your mind at any time in Settings → Privacy, and the change takes effect immediately — no restart.
What the switch does and does not cover:
Turning these off does not degrade Helm in any way.
To delete all Helm data from your machine:
~/.vibe/ directory.vibe/ directories within your project foldersFor deletion of crash-report or analytics data from our providers' servers, contact us at privacy@helm.dev.
Helm is not intended for use by children under 13. We do not knowingly collect information from children under 13.
Helm is intended for adults and is not directed to children. If you are in the EEA or the United Kingdom, do not use Helm or join the waitlist unless you are at least 16, or older where your country sets a higher age for consent to online services.
Helm can generate privacy-policy, terms-of-service, and cookie-notice templates for the applications you build with it, including a section listing third-party services detected in your project's code.
Those templates describe your application, not Helm, and they are informational only — not legal advice, and no warranty that they are legally sufficient. You are responsible for the privacy policy your own applications publish. See Section 10 of our Terms of Service, and the disclaimer in every generated file.
This policy is mostly about the Helm app. This section is about the helm.dev website.
Visiting. helm.dev sets no cookies and runs no analytics. Like any website, our host (Cloudflare) sees your IP address when it serves a page. The site does not respond to Do Not Track browser signals, because it does not track you across websites in the first place. Some pages may load fonts or other assets from a third-party content network; when they do, that provider receives your IP address and browser details for that request, and nothing else about you.
Joining the waitlist. If you give us your email address we keep it, together with when you joined and, if you arrived through a referral or a tracked link, which one. We do not store your name, IP address or browser details with your signup. If you use a referral link we assign you a referral code and count the people who join through it. When someone opens a referral or tracked link we record the link's code, the time, and the first 80 characters of the browser's user-agent string (the text a browser sends to identify its type), so we can count how often each link is opened and filter out bots. That click record identifies the link, not the person who opened it: it holds no email address, we do not match it to any signup, and we keep it until we purge it. For abuse prevention and security, we may also record the IP address and full browser details of requests to the waitlist and its links; when we do, we keep that record apart from your signup and use it only for those purposes.
What we send. One welcome message with your place in line and your referral link; occasional updates about Helm; and, when it is your turn, the single message that invites you in. Our email delivery provider (currently Resend) processes your address and the message content to send them. Every update carries an unsubscribe link and our postal address.
Stopping the emails and leaving the list. Every update carries an unsubscribe link, and unsubscribing stops the updates immediately; you will still receive the invitation when your spot opens. To be removed from the list entirely, reply to any of our emails or write to privacy@helm.dev and we will delete your record. We keep waitlist records until you ask us to remove them or until we close the list, and we delete the records of a closed list within 12 months.
Where it lives. The waitlist is stored for us by Cloudflare. Nobody else receives it, and we do not sell or share it.
This section applies if you are in the European Economic Area (EEA) or the United Kingdom. For the processing described in this policy, Helm Dev, Inc. is the controller, and you can reach us at privacy@helm.dev or at the postal address in Section 17.
Lawful bases. Helm provides the Software and any paid licence, runs licence checks, and operates the trial lane to perform its contract with you or to take steps at your request before a contract (Article 6(1)(b) of the GDPR). It fetches configuration and legal text on launch, keeps its model and status information current, checks dependency licences and custom domains, and protects the trial lane against abuse on the basis of its legitimate interests in operating and securing the Software (Article 6(1)(f)). It collects crash reports and usage analytics, sends error and scenario reports, and runs the dependency-advisory check only with your consent (Article 6(1)(a)). It sends waitlist emails on the basis of your consent.
Your rights. Subject to the conditions in the law, you may ask us to give you access to your personal data, correct it, delete it, restrict or object to its processing, or provide it in a portable form. Where we rely on consent, you may withdraw it at any time, and withdrawing is as easy as giving it: use the switch in Settings, the unsubscribe link in an email, or write to privacy@helm.dev. Withdrawing consent does not affect processing already carried out. We do not make automated decisions that produce legal or similarly significant effects about you.
How to exercise your rights. Write to privacy@helm.dev. We respond within one month, and we do not charge for a request unless the law allows it. Because much of what Helm holds sits on your own machine, we will also tell you when a request is one you can carry out yourself, and how.
Complaints. If you believe we have handled your personal data unlawfully, you may lodge a complaint with your local supervisory authority; in the United Kingdom that is the Information Commissioner's Office.
International transfers. Helm Dev, Inc. is in the United States, and the providers in Section 8 that process personal data for Helm (currently Sentry, PostHog, Cloudflare, Resend and our licensing provider) also process it in the United States. When personal data moves from the EEA or the United Kingdom to the United States, we rely on the EU-U.S. Data Privacy Framework and its UK extension for providers certified under it, and on the Standard Contractual Clauses with the UK Addendum for providers that are not. Ask us at privacy@helm.dev which mechanism covers a given provider.
Our representative. Before we open the beta to users in the EEA or the United Kingdom, we will appoint a representative under Article 27 of the GDPR in the EEA and the United Kingdom, and we will name that representative here.
We may update this Privacy Policy from time to time. Changes will be reflected in the "Last updated" date. We will notify you of significant changes through the application.
For a material change, we will post the updated policy with a new Last updated date and give notice inside the app, and, where we hold your email address, by email before the change takes effect. If you keep using Helm after that date, the updated policy applies.
Helm Dev, Inc. is the data controller for the information described in this policy. For privacy-related questions or requests, contact us at privacy@helm.dev, or write to Helm Dev, Inc., 1401 21st Street, Suite 12332, Sacramento, CA 95811, USA.