Privacy

Data and controls

Updated September 26, 2026

Moorline runs coding agents on the gateway machines you choose. This page explains the app and website's data flows and controls. Self-hosted services and your agent providers have their own configuration and policies.

Sessions and agent providers

The gateway stores session metadata and conversation history on its machine. Connected clients retrieve that history. Agents receive the prompts, files and tool access needed for your requests and may send data to their own providers. Moorline's telemetry settings do not control those provider calls. Review your agent's permissions and provider settings.

Accounts and the website

Accounts support browser and app sign-in and admission to the configured hosted relay. The account database stores your name, email, optional profile image, login-provider records, password credential when applicable, verification records and session data. Session records can include IP addresses and user-agent details. Authentication cookies keep browsers signed in; the native app stores its account token locally. Rate-limit counters can be keyed by IP address or email address to limit abuse.

The site runs on Cloudflare Workers and D1. When configured, GitHub handles GitHub sign-in and Resend delivers account email. A release-list signup stores your email, signup date and an unsubscribe token separately from your login account. Operational infrastructure can process request metadata and logs in addition to the application records described here.

Remote connections and push

Clients register app and gateway endpoint public keys with the account service for hosted relay admission. Those records include the owning account, endpoint kind, optional label and timestamps; an app's own records are tied to the session that registered them and go when it signs out. A machine linked to an account stores its endpoint public key, label, relay URLs and when it was linked and last seen, and asks the account service whether each connecting device belongs to that account. The relay carries encrypted gateway connections and can observe network connection metadata. Pairing credentials, or a device signed in to the account a machine is linked to, authorize access to the gateway itself. Local sessions do not require an account; independently hosted relays can use their own admission rules.

Where mobile push is configured and supported, the service receives a device token to issue a signed grant and forwards encrypted notification payloads to Apple Push Notification service or Firebase Cloud Messaging. The push routes do not store a device registry or payload history in D1, but they do store rate-limit counters. Device support and provider configuration determine whether delivery is available.

Crash and error reports

Crash reporting is on by default when a Sentry endpoint is configured. The app and gateway report panics and errors; the website can report uncaught route errors. Reports include error type/message, stack information, release and technical runtime or device context. App and gateway reports use separate random installation IDs, not your account ID. Website reports can include the request method and path.

Code filters recognized sensitive patterns and limits error messages. It does not intentionally attach prompts, transcripts or file contents. Filtering cannot guarantee that all sensitive text is removed from every error. The app/gateway integration disables breadcrumbs, automatic sessions and performance traces, and does not collect memory dumps. The website strips request queries, headers, cookies and bodies from error reports.

In the app, turn off Options → General → Privacy → Send crash reports. The app also requests that setting for its local gateway; remote gateways have separate settings. Gateway operators can set crash_reports: false in telemetry.json or start with GW_TELEMETRY=0. Website reporting is controlled by its operator's Sentry configuration.

Optional usage data

Usage reporting is off by default. If you enable Options → General → Privacy → Share anonymous usage data in a build configured for PostHog, it sends app-opened, machine-added, chat-started, chat-turn-completed, agent-installed and sign-in-completed events. Properties include a random installation ID, app version, OS/browser/device/screen details, and where relevant the machine kind or agent identifier. That stable random ID is pseudonymous.

This integration does not enable prompt capture, pageviews, referrers, session recording, autocapture or tracking cookies. Its PostHog state is held in memory. Turning the setting off stops subsequent usage capture. Builds without the corresponding telemetry keys do not initialize those clients; a development build is not exempt if keys are supplied.

Network services, including Sentry and PostHog, can see the IP address a connection comes from. This page does not assert that hosted IP-discard or retention settings have been independently verified. The telemetry reference describes the source-level filters and fields.

Your controls

Use Account to export account data, revoke sessions or delete your login account. The export excludes bearer credentials. Account deletion removes related account/session, relay registration and linked machine records; release-list subscriptions are separate and use their unsubscribe link. Deleting an account does not erase history stored on your gateway machines or records held independently by your agent providers.

Local data, telemetry services and hosting backups have separate lifecycles. This disclosure does not promise a universal deletion or retention period. For questions about the documented behavior, use the project issue tracker without posting personal data. For a vulnerability, follow the private security reporting instructions.