Three things leave.
Here is the list.

The workspace runs as a local web server bound to 127.0.0.1:3000 on a machine you own. Your chats, your files, your search index and your screenshots are written to ~/.meshvault/workspace/ on that machine's disk. FireDev LLC has no server that receives them. We cannot read them, we cannot recover them, and we cannot delete them for you.

Checked on the pilot node while writing this page:

$ ss -ltnp | grep -E ':3000|:11434'
LISTEN 0 511  127.0.0.1:3000  0.0.0.0:*  users:(("next-server (v1",pid=506691,fd=22))
LISTEN 0 4096 127.0.0.1:11434 0.0.0.0:*

Both are loopback. The second is Ollama, which is where model inference happens.

1. Pages the browser arm visits

When you or the agent navigates, a headless Chromium on your machine makes an ordinary HTTP request to the site you named. That site sees what it sees from any browser: your IP address, your user agent, whatever its own scripts collect. We are not a proxy and we do not see that traffic.

2. Payment traffic to Stripe, when you configure it

With no Stripe secret key set, no request is ever made to Stripe. With one set, the workspace calls Stripe's REST API directly, with no SDK in between. Card numbers never touch your node; checkout happens on a Stripe-hosted page. The code refuses to create a checkout session with a live key at all, which is what keeps the pilot a pilot.

3. Things you deliberately send

An approved reply, a form the browser arm submits after you approved it, a file you told it to upload. Every one passes the approval gate first. Nothing in the application sends, spends, deletes or deploys on its own.

There is no analytics SDK, no telemetry endpoint, no crash reporter and no error-tracking service in the codebase. Verified 2026-07-27 by searching every TypeScript and TSX file for the usual suspects and reading every outbound fetch to an https host. The only external hosts any code path reaches are Stripe's API and whatever URL you hand the browser arm.

We receive no crash reports, no feature usage counts, no model names, no prompt text and no error messages. There is no signup, no account and no email list for the workspace software.

Three things people reasonably assume are connected and are not: Composio is a stated policy with no code behind it, MCP servers you register are a list in a settings file that nothing connects to, and the mesh moves no traffic. Being wrong in the reassuring direction is still being wrong.

The index is built from Markdown in your vault and from skill bodies on your path index. If personal information is in those files, it is in the index sidecars in readable form. That is worth knowing before you point the indexer at a directory.

One headless Chromium process runs on your machine. Each navigation creates a fresh browser context, so cookies and storage from one navigation do not carry into the next.

To disk, per call: a PNG for each screenshot, up to 4,000 characters of visible page text for each snapshot, up to 2,000 characters of the JSON result of an evaluate call, and the page title and final URL in the transcript. A screenshot captures whatever is on the page, including anything personal rendered there. Those files are never uploaded and nothing deletes them on a schedule. On the pilot node the directory reached 61 files in about three hours of testing.

Reading is gated at your configured level. Clicking, filling a form and running JavaScript in the page are always-ask actions, and L3 blocks them entirely.

Settings has a panel that clears data by source. Clearing chat history removes transcripts with no task attached. Clearing task history removes each task card and the transcript it spawned. Clearing screenshots unlinks every file in the browser directory. All three take effect immediately, with no trash, no undo and no export first.

This list matters more than that one:

1. Approval records survive. Nothing in any clear action touches them, and their payloads hold what you approved.
2. The embedding index survives. The sidecars keep the full text of every indexed chunk until the index is rebuilt from a corpus that no longer contains it.
3. The older JSON retrieval index survives, for the same reason, in a separate file.
4. The reindex queue survives and is never truncated. It holds timestamps only, never content.
5. Your vault is untouched. It is a separate store with its own lifecycle and nothing here deletes from it.
6. Hand-editing a store file is not clearing. Restart the daemon after doing it, or a cached copy keeps serving and a pending write can land on top of your edit.
7. Unlink is not erasure. The blocks stay on disk until overwritten, and any backup or synced copy your operating system made is out of this application's reach.

Only three things expire on their own: login sessions after 30 days, pairing invites after 10 minutes, and pending pairing requests after 3 minutes. Everything else is kept until you delete it. There is no retention timer.

We cannot delete anything for you, because we do not hold it. A deletion request sent to us for on-device data has nothing to act on.

This is a description of software behaviour on a specific date. It is not legal advice and it is not a privacy policy. A full workspace policy exists in draft, has not been reviewed by counsel, and is not published; publishing it early would be worse than publishing nothing.

The policy that does govern this website, the skills pack checkout and any support mail you send is at /privacy. Terms are at /terms. Refunds are at /refunds.

Every claim above is true of the code on 2026-07-27. A future build that adds a crash reporter without changing this page turns an accurate sentence into a false one, which is why the page carries its date in the header rather than in a footnote.