Privacy Policy | What Meetless reads, and what it sends

1. Who we are and what this covers

Meetless ("we," "our," or "us") provides an active source of truth for AI coding agents. This Privacy Policy covers three surfaces:

This website (https://staging.meetless.ai) and our research site.
mla, the command-line client that runs on your own machine.
The hosted backend and Console at https://app.meetless.ai, when you point mla at ours rather than at your own.

That last point matters more than anything else on this page. mla talks to whichever backend you configure. If you run your own, the governed content and usage counters described below go to your server and we never receive them, and only the "this website" sections apply to you.

2. What mla reads on your machine, and what stays there

mla is local-first. It reads your repository, your agent session transcripts, and your governed memory files from disk in order to work. Reading is not sending.

These never leave your machine:

Your source tree. We do not upload your repository.
Your prompts and your agent's replies, except where you explicitly capture a decision from them.
Command arguments, query strings, and error messages, in any usage counter we receive.
Any identifier derived from your content. Where a counter needs to describe a file, it carries a coarse category (code, tests, docs) rather than the path, with the single exception stated immediately below.
Diagnostic bundles produced by the CLI. They are written to disk for you to inspect and send, if you choose to.

The one exception, stated plainly:

When a governance rule you wrote blocks a write in your own repository, the counter for that block carries two things beyond a category: the text of your rule, and the path it blocked. This exists so the review queue in your Console can show you what was blocked and on what basis; a block you cannot see the substance of is a block you cannot judge. The path is always relative to your repository and never an absolute path, so it does not describe your machine or where the repository sits on it. Both fields stop at the backend you configured. If that backend is ours, we hold them for your workspace only, and they are not forwarded to our analytics provider, which continues to receive the coarse category instead of the path.

Injecting governed context into an agent's prompt is a local file read. It makes no network request and calls no model.

3. Governed content you submit

When you record a decision, capture a project-memory file, resolve a conflict, or close out a session, that content is sent to the backend you configured and stored there. This is the product working as described: a shared, queryable source of truth is not possible without storing what you chose to put in it.

Two limits are worth naming, because both are enforced in the client rather than promised in prose:

Memory capture is opt-in by classification. Only memory files you have marked as project-scoped are eligible for upload. Personal notes, feedback, and reference files are skipped, and eligibility is decided by the file's own metadata, never by its name or location.
A credential in the payload stops the request. Content is scanned for high-confidence secret formats before it is sent. On a match the client refuses the whole request and tells you, rather than uploading a redacted version and leaving you to assume it went through. Only the name of the rule that matched is recorded, never the matched value.

Every outbound request the client makes is resolved against an explicit policy that declares which fields may travel and whether free text is stripped first. A request with no policy entry is not sent. New fields therefore fail closed: they are withheld until somebody classifies them.

4. Usage telemetry, and how to turn it off

mla has exactly three outbound telemetry planes. Two are off unless you or your server turn them on.

Plane	Default	What leaves
Crash reporting	Off	Nothing. Open-source builds carry no crash-reporting key, so the reporter never initializes.
Run traces	Off	A per-run batch of command names, timings, and redacted arguments, sent only to the backend you configured, and only if that backend opts in.
Product-health analytics	On, opt-out	Ids, counts, rates, durations, closed enums, and one-way hashes. No prompt text, no paths, no arguments, no file contents.

The analytics plane exists to answer one question: is governed memory actually helping? How often evidence gets injected, consulted, and acted on; where coverage is thin; whether the hooks are reliable. Events are written to a local log on your machine, which is what the CLI's own stats command reads, and forwarded to your configured backend. The CLI holds no analytics key of its own.

To silence all three planes at once, set either of these in your environment:

export MEETLESS_TELEMETRY=off   # accepts: off | 0 | false | no
export MEETLESS_NO_TELEMETRY=1  # any truthy value

With it set, crash reporting refuses to initialize, the trace plane becomes a no-op, and nothing is forwarded. Local recording for your own stats keeps working, on your disk, and can be disabled separately. The CLI prints a one-line disclosure of this the first time you initialize it.

5. Authentication credentials are not telemetry

Signing in stores your access and refresh tokens, or a shared workspace key, in a config file on your machine. These are request credentials, not data we collect: they are sent only to the backend the CLI is pointed at, and only as proof needed to authenticate that request. They are never attached to a crash report or a trace batch, and the CLI's identity commands print who you are and how long your session has left, never the token itself.

6. Information you give us directly

Account information (name, email address, organization), handled by our authentication provider.
Communications with us: support requests, bug reports, feedback, and anything you attach to them.
If you connect an optional integration, the data that integration's permissions grant us, limited to what the feature you enabled needs.

7. This website

Separately from the CLI, this marketing site collects ordinary web analytics: pages visited, referrer and campaign parameters, approximate location derived from IP address, and browser and device type. We use Google Analytics and PostHog for this. Your browser settings and any tracking-protection extension you use govern what these can see.

8. How we use information

Provide, operate, and maintain the service
Store, index, and retrieve the governed content you submit, so your agents and teammates can be steered by it
Communicate with you about your account and material changes
Measure whether the product works, using the ids-only counters described above
Detect, prevent, and address security issues and abuse
Comply with legal obligations

We do not train models on your governed content or your source code.

9. How we share information

We do not sell your personal information. We may share information with:

Service providers who run parts of the platform on our behalf: cloud hosting, authentication, analytics, model inference for the features that need it, and support tooling
Integrations you have authorized, and only for the actions you asked for
Legal authorities when required by law or to protect our rights
Business transfers in connection with a merger, acquisition, or sale of assets

10. Data retention

We retain your information for as long as your account is active or as needed to provide the service. Governance records are append-only by design: a decision and the audit trail behind it are the artifact, so superseding a decision adds a record rather than erasing one. You can ask us to delete your workspace content at any time (section 11), and we may retain limited information where the law requires it.

11. Your rights

Depending on where you live, you may have the right to:

Access the personal information we hold about you
Request correction of inaccurate information
Request deletion of your information
Object to or restrict processing of your information
Receive your data in a portable form
Withdraw consent at any time

To exercise any of these, email hi@meetless.ai. We answer within 30 days.

12. Data security

Data is encrypted in transit and encrypted at rest by our cloud provider. Access to production systems is restricted and audited. The outbound policy and the credential scanner described in section 3 are part of this posture rather than separate from it: the cheapest way to keep a secret safe is never to receive it. No system is perfectly secure, and we will tell you promptly if something affecting you goes wrong.

13. Cookies

We use cookies and similar technologies for authentication, analytics, and preferences. You can control cookies through your browser settings. Disabling some of them will break sign-in.

14. Third-party links

Our site links to third-party websites, including our source repository and our published research. We are not responsible for their privacy practices.

15. Children's privacy

Our services are not directed to individuals under 16. We do not knowingly collect personal information from children. If you believe we have, contact us and we will delete it.

16. Changes to this policy

We may update this policy. Material changes will be posted here with a new "Last updated" date, and we will email account holders when a change affects what we collect or how we use it.

17. Contact us

Questions about this policy, or about anything above:

Email: hi@meetless.ai

Read the client: github.com/Meetless/mla