Privacy policy

1. Who we are and what this covers

Worktree is operated by four individual cofounders based in Texas, United States, without a separately incorporated legal entity. The final notice must identify the individual operators by their legal names. You can contact privacy@tryworktree.com about personal information and support@tryworktree.com for general assistance. This document is a draft dated September 30, 2026, and has not yet taken effect.

This notice describes the website, the current account-free desktop alpha, and the hosted infrastructure used to arrange project sharing. It distinguishes data kept on participant computers from information processed by the Worktree operators and their infrastructure providers. It does not govern a project host’s independent processing, your employer’s systems, or an AI provider or integration you choose.

‘Personal information’ means information that identifies, relates to, or can reasonably be linked to a person, subject to the definitions in applicable law. Device identifiers, public keys, IP addresses, display names, and project metadata can be personal information even when no email-based account exists. We do not describe the product as collecting no data.

2. The main data boundaries

Your project’s source files and session history ordinarily reside on its host computer. Approved collaborators may access permitted files, messages, tool results, and previews over a shared connection. The hosted coordinator stores the metadata and authorization state needed to establish and maintain sharing; it is not intended to serve as a hosted repository or transcript-sync store for the current alpha.

Provider credentials are managed by the computer that owns the provider connection. A guest can use its own local provider connection for a project shared by another computer. This does not mean the prompt stays on that computer: relevant session context is sent to the selected provider, and generated output returns to the shared session. The host and authorized collaborators may see that output.

The hosted relay forwards encrypted endpoint traffic. Encryption of that traffic does not conceal all connection metadata or protect content after it reaches an authorized endpoint. The coordinator participates in initial discovery and authorization. A compromised computer, approved participant, executable plugin, or provider is a separate trust boundary.

3. Information stored on computers

Depending on use, the desktop stores project locations and settings, session messages, prompts and outputs, tool results, local caches, provider connection details, device identity material, approved remote-project references, and preferences. Project files may also be changed by agents or collaborators acting with the permissions you grant. The operating system, backup tools, and other software on that computer may hold additional copies.

Device private keys and provider secrets are not submitted to the project-sharing coordinator as part of the normal account-free sharing protocol. We do not promise that locally stored information is immune from malware, other operating-system users, a compromised device, or executable code you authorize. Protect the host, its backups, and the profile containing credentials.

Deleting a chat, leaving a project, resetting a profile, and uninstalling the app are different actions. An uninstall may leave application data or backups behind. Deleting data on one computer does not erase copies on another participant’s computer, in a provider’s systems, in a repository’s history, or in an external service.

4. Sharing and device metadata

The hosted sharing service processes share and peer identifiers, device identifiers, credential verifiers, public certificates, project display metadata supplied by the host, participant profile fields such as display names and avatars when provided, and approval or revocation state. It also processes invitation verifiers and expiration times, channel identifiers and nonces, presence and lease times, and related creation or update timestamps.

The purpose is to locate the intended project, let the host approve a device, bind a connection to the expected endpoints, maintain availability, enforce permissions and revocation, and prevent abuse. A display name is not verified identity. Hosts and approved peers can receive the profile and membership information needed for the shared project; pending guests do not receive the same access as approved guests.

Not every hosted metadata record disappears when a device goes offline. Stopping sharing, revoking access, and removing a local project reference have different effects. Expiring an invitation or connection lease prevents its continued use; it does not necessarily erase the associated database record immediately.

5. Website visits, security, and diagnostics

Requests to the website and hosted APIs expose network and request information to the hosting infrastructure, such as IP address, request time, route, response status, and browser or client characteristics. Hosting and security providers may process that information to deliver content, detect abuse, and operate their infrastructure. Application error and operational logs may include error messages, identifiers, timings, and relevant diagnostic details.

The demo-request flow uses a short-lived challenge and a request fingerprint for abuse prevention. The request fingerprint is derived from request information rather than being an account password. Rate-limiting and challenge records can persist independently of a successful form submission. Do not place confidential information in URLs or assume error messages are always free of user-provided text.

The desktop source supports optional error reporting when a Sentry endpoint is configured for a build. Such reporting can include exception messages, stack traces, release information, and diagnostic context. The release configuration must be checked and disclosed before distribution; this draft does not promise that all distributed builds have telemetry disabled. Diagnostic exports you voluntarily send can also contain local paths and project-related information. Review and redact them before sending.

6. Demo requests, support, and other communications

If you request a demo, the form collects your name, email address, company, role when supplied, team size, message when supplied, the request source, and operational information needed to admit and process the submission. These details are stored in the service database. A configured notification integration may forward the request to the team’s chosen communication service so the team can respond.

If you email us or report a problem, we process your address, the content of the correspondence, attachments you choose to send, and records of our response. We use this information to answer you, arrange a demo, troubleshoot the issue, maintain continuity of support, and protect the service. Do not send passwords, API keys, private certificates, sensitive personal records, or a complete repository unless we have agreed that it is needed and how it will be handled.

A support or demo request is not blanket consent to unrelated marketing. If we later offer an optional marketing mailing list, its purpose and any required consent or opt-out will be presented separately. The current alpha does not require you to create an account or provide payment-card information to use the desktop.

7. AI providers and external tools

When you select an AI provider, Worktree sends the model inputs needed for that operation through your configured connection. Inputs can include prompts, conversation history, system instructions, file excerpts, attachments, tool definitions, and tool results. A file does not need to be manually uploaded to become relevant context for an agent you authorize to read it.

Providers can process prompts, outputs, authentication information, and usage records under their own terms. Their retention, training, abuse-monitoring, regional processing, and deletion settings vary. Worktree does not control them and does not promise zero retention or a no-training setting on their behalf. Review your chosen provider’s terms and account controls, especially before using confidential or regulated material.

An agent may also contact services through tools, browser automation, plugins, MCP servers, package managers, repository integrations, or shell commands. The destination receives whatever information the authorized action transmits. Worktree’s local credential design does not mean all execution is local or that third-party integrations inherit this policy.

8. Why information is processed

We process hosted information to deliver the requested website and sharing functions, establish approved connections, maintain device authorization, respond to requests, investigate failures, prevent abuse, enforce service limits, and comply with applicable obligations. We may use operational information to understand reliability problems and improve the specific service involved.

Where a law requires a legal basis, the relevant basis may be providing a service you request under an agreement, legitimate interests in secure and reliable operation where not overridden by your rights, compliance with a legal obligation, or consent for a genuinely optional activity that requires it. We do not treat acknowledgment of this policy as consent for every activity.

If we propose a materially different use, we will explain it and obtain consent when required before beginning that use. The current design does not give the operators routine access to plaintext repositories through the encrypted relay, and it is not a project-content collection program for training an operator-owned AI model.

9. Recipients and service providers

Information can be disclosed to the project host and approved collaborators as necessary for the permissions and features you use; to the AI providers and external tools you select; and to infrastructure or communication providers that operate the service for us. The current architecture uses Vercel for website and API hosting, Supabase for hosted coordination and form records, and Daytona-hosted infrastructure for the project relay. Email, notifications, and optional diagnostics involve the providers configured for those functions.

Provider names describe the current architecture, not a promise that every request goes to every vendor. Before public release we must verify the deployed vendor configuration, processing locations, diagnostic settings, retention settings, and applicable contractual safeguards. The team’s access should be limited to what is needed for operation and support.

We may disclose information when legally required, to respond to valid legal process, or where reasonably necessary to investigate abuse and protect rights or safety. We may transfer relevant information if the project’s operations move to a new operator, subject to appropriate notice and applicable law. A recipient does not acquire permission for unrelated uses merely because the project changes operators.

10. Cookies, local storage, and advertising

The app and website can use local storage, preferences, caches, and necessary state for functionality. Request challenges and infrastructure security mechanisms may also be used to prevent abuse. These are distinct from an advertising profile. The current website source does not integrate an advertising pixel or general-purpose marketing analytics SDK; hosting providers can still record requests and operational metrics.

The current product is not designed to sell personal information, share it for cross-context behavioral advertising, or build advertising audiences from project activity. If a future feature changes those practices, the notice and any required consent or opt-out mechanisms must change before it is enabled. Applicable legally required privacy preference signals will be respected.

Browser controls can restrict cookies and clear website storage, but doing so may affect functionality and does not erase server records. Clearing desktop profile storage may also remove the credentials needed to reconnect to shared projects. Consider the consequences and preserve needed backups before resetting a device.

11. Retention and deletion

Different data has different lifetimes. Local files and session data remain under the control of the relevant computer’s user and its backup systems. Hosted membership and approval records support reconnection and authorization and can remain after a device is offline. Connection tickets, leases, and invitations expire for authorization purposes, but their expiration must not be confused with guaranteed immediate deletion from storage.

The alpha does not currently promise a universal automatic deletion deadline for all hosted metadata, support messages, security logs, or backups. Retention is determined by the operational purpose, active sharing relationships, provider settings, security investigations, and applicable legal obligations. The final release needs a documented and implemented schedule rather than an invented number in this policy.

You can request deletion of information under the operators’ control at privacy@tryworktree.com. We will assess the request under applicable law and explain any information that must be retained and the relevant reason. Backup copies may be removed through their normal expiry cycle rather than immediately overwritten. We cannot remotely erase another participant’s independent copies or direct an unrelated AI provider’s deletion process.

12. Security and its limits

The sharing design uses endpoint encryption, saved key identities, host approval, scoped authorization, expiring connection authority, and resource limits. These controls reduce risk; they are not a guarantee that every vulnerability has been found or that every device is trustworthy. The product is in alpha, and security defects can exist.

Execution permissions require particular care. Agent shell On can permit code to run with host privileges. Ask may permit an individually approved command. Off and Ask restrict ordinary guest writes and raw terminals in the current release, but permissions are not an operating-system sandbox. A trusted person or agent with sufficient access can copy, modify, or transmit information.

If you suspect exposure, stop affected sharing, revoke relevant access, rotate compromised third-party credentials, preserve useful evidence, and contact support@tryworktree.com. Do not send the secret itself. We will investigate reports and provide legally required notifications if an incident triggers such obligations.

13. Your choices and privacy rights

You can choose whether to share a project, approve a device, connect a provider, submit a form, or send diagnostics. Hosts can change collaborator permissions and stop sharing; guests can leave. Local use and hosted sharing involve different processing. Withholding information needed to establish a connection or answer a request can prevent that function from working.

Depending on your location and applicable law, you may have rights to request access, correction, deletion, a portable copy, restriction, or an explanation of processing; to object to certain processing; to withdraw consent where it is the basis; and to complain to a relevant supervisory authority. Some laws also provide appeal rights when a request is denied. We will not unlawfully discriminate against you for exercising a right.

Send requests to privacy@tryworktree.com and identify the relevant device, project, or correspondence to the extent you can safely do so. We may need proportionate verification to avoid disclosing information to the wrong person. We will not ask you to email a private key or provider secret. Because there is no account directory, we may not be able to identify every record from an email address alone. Authorized agents may submit requests subject to applicable verification rules.

Rights and response deadlines depend on the law that applies, and exceptions may protect security, other people’s rights, legal records, or claims. If a request cannot be fulfilled, we will explain the applicable reason and available appeal route rather than promise a right that the service cannot deliver.

14. International use and sensitive information

The operators are based in the United States. Infrastructure and selected AI providers may process information in other locations, depending on deployment and your configuration. This alpha does not promise processing confined to a particular country, an enterprise data-residency commitment, or suitability for regulated data. Where transfer safeguards are legally required, the applicable arrangements must be established before the relevant processing.

Do not submit information that you are prohibited from disclosing to the relevant host, collaborators, provider, or infrastructure service. The hosted alpha is intended for adults and does not knowingly solicit personal information from children. If you believe a child has provided information to the team, contact privacy@tryworktree.com so we can investigate and take appropriate action.

If an organization uses Worktree to process personal information on its own behalf, that organization may have separate obligations to its personnel and customers. This public notice is not a data-processing agreement, confidentiality agreement, business associate agreement, or certification of regulatory compliance.

15. Changes and contact

As the alpha evolves, we may update this notice to reflect changes in processing. We will revise the date and provide additional notice for material changes where appropriate or required. If a change requires consent or another legal step, posting a revised notice alone will not substitute for it.

Contact privacy@tryworktree.com for privacy questions, requests, or complaints, and support@tryworktree.com for product and security issues. The final published notice must identify the individual operators and an appropriate contact address. You may also exercise rights with an applicable regulator without first giving up other legal remedies.