Privacy, without the fog.

01Scope

This Privacy Policy applies to ThreadOps websites, hosted applications, collectors, plug-ins, and related support interactions (together, the “Service”). It does not govern a third-party service merely because you connect it to ThreadOps. That provider’s own policy applies to its handling of data.

02Data we handle

Account and workspace information

We handle details you provide, such as your name, email address, workspace name, authentication method, membership role, and account preferences.

Operational metadata

When you connect a machine or coding agent, the Service may receive a device name, hostname, platform, provider, session state, timestamps, repository name or local path, branch, recent commit subjects, author names, timestamps and SHAs, dirty/ahead/behind state, and related pull-request, task, review, or deployment status. The collector does not send commit author email addresses.

Connected-service data

If you choose an integration, ThreadOps processes the credentials, account identifiers, selected scope, and records needed to provide that connection. Depending on the provider and features you enable, records may include tickets, assignment and workflow state, selected-channel messages, task titles and statuses, repository and build activity, and deployments. Builder tools configured as reference-only store only the project URL you submit. Access tokens, webhook secrets, and similar secrets are treated as credentials, not display data.

Release-control actions

If you enable GitHub release control, the credential must be able to request a pull-request merge. GitHub exposes that operation through repository Contents write permission. ThreadOps does not use that permission to collect source-file contents. It uses the merge endpoint only after an authorized member approves a frozen commit, all configured gates pass, and the evidence is revalidated immediately before the action. We record the actor, approved commit, resulting merge commit, policy, and provider response as release evidence.

Team collaboration data

When you collaborate in a workspace, we process invitations, memberships, roles, invitation acceptance and revocation, and the actors recorded for release approvals and merges. This information is visible to other authorized members of that workspace as appropriate to their role.

Provider action data

If an authorized member asks ThreadOps to act in a connected service, we process the requested action, actor, target, result, and related error or audit details.

Notification and reply data

If a workspace turns on orchestrator notifications, ThreadOps posts operational summaries — task titles, stage and check states, and short agent-produced diagnoses — to the Discord channel that workspace selected, and reads that channel's new messages to apply code-based replies. To attribute a reply, we store the Discord account identifier a member verifies with a one-time code; members can unlink it at any time. Content posted to a connected channel is also governed by that provider's own policies.

Task handoff and remote-execution data

If you connect a provider-run agent, ThreadOps stores its encrypted, scoped dispatch credential and sends the task instructions and context you select to that provider. For a Claude Routine, ThreadOps records the session identifier and URL Claude returns, but the trigger cannot read the session or its transcript. Claude runs the agent under your Claude account and plan; ThreadOps does not run it or pay for its usage.

If you instead enable task handoff on a computer or VM you control, the Service processes worker identity, public-key, supported-runtime, approved-project, availability, capacity, trust-policy, and execution-state metadata. A dispatch includes task instructions and any context you explicitly select, plus status, results, and optional logs or artifact metadata returned by that worker. In either path, dispatched instructions may contain prompt or workspace content you choose to send.

Op transcripts

If op transcripts are enabled for a machine, its local worker records the agent's output for tasks dispatched from ThreadOps, and its collector reports the latest reply of each local agent session it observes: the last assistant message only, at most its final 4,000 characters, never prompts or instructions. Both are redacted for recognizable secrets before they leave the machine, stored encrypted, and shown only to workspace members whose role permits sending ops. While the setting is off, the collector remains metadata-only and no reply leaves the machine. The setting is off by default for local machines; it can be turned off at any time.

Attachments and dictation

Files you attach are kept in your browser draft until sent or removed. When sent, they are encrypted with the task instructions and available to workspace owners, admins, and members, but not viewers. A compatible computer worker receives the files for the selected task. File contents may then be processed by the agent and its model provider under your configured permissions.

Dictation sends your recording to OpenAI Whisper after you stop recording. ThreadOps does not store that audio on its server. A failed recording remains in the open composer for manual retry or removal. The transcript enters your editable draft; it is not sent to an agent until you choose Send. OpenAI processes audio under its applicable API data policies. ThreadOps keeps usage counters to enforce transcription limits, not audio in those counters.

Service and security data

We may process IP address, browser and device information, request timestamps, error reports, authentication events, security-verification results, and similar logs needed to operate, diagnose, and protect the Service.

Product usage analytics

After you sign in, ThreadOps records the product page path, visible active time, a random page-view identifier, coarse country or region supplied by the hosting edge, and available campaign or external-referrer information. This helps us understand signup, connection, adoption, and where people spend time. Hidden or background tabs do not add active time. These analytics do not include prompts, responses, source files, diffs, credentials, environment variables, or device tokens.

03How we use data

We use information to:

• create and secure accounts, workspaces, and sessions;
• receive, organize, and display agent-work metadata;
• connect services, link related records, and reconcile work across tools;
• send authorized Jira assignments and workflow transitions, and approved GitHub merges, to connected providers;
• route authorized task handoffs to approved machines and agent runtimes and return their results;
• maintain synchronization records and release evidence;
• deliver transactional messages and account recovery;
• prevent abuse, investigate incidents, and enforce limits;
• debug, maintain, and improve Service reliability; and
• measure signup, connection, adoption, and product-area engagement; and
• comply with law and protect users, the Service, and others.

Depending on where you live, these activities rely on performance of our agreement with you, legitimate operational and security interests, consent where requested, and compliance with legal obligations.

04Sharing and providers

We disclose information only as needed to operate the Service: to infrastructure, database, email, authentication, monitoring, fraud-prevention, and support providers; to integrations you direct us to use; to professional advisers under appropriate duties; or when required by law or necessary to protect rights and safety.

Workspace information is shared with authorized members of that workspace according to their role. When you request an action, notification, or synchronization involving a connected provider, ThreadOps sends the information and instructions needed to that provider. The action may change a record in that provider, and the provider separately handles information under its own privacy policy and terms.

For task handoff, ThreadOps sends the selected instructions and context either to the provider account you connected or to an approved worker on a computer or VM you control. A third-party agent or model provider may receive that content under the account, terms, charges, and privacy policy that apply to your selected destination.

We may transfer relevant information as part of a merger, financing, acquisition, reorganization, or sale of assets, subject to appropriate confidentiality and notice obligations.

05Retention

We keep account, workspace, and operational records for as long as reasonably needed to provide the Service and maintain the work history you request. Security logs, backups, and records required for fraud prevention, disputes, or legal compliance may remain for a limited period after other data is removed.

Retention can vary by data type, workspace settings, contractual commitments, and legal requirements. When data is no longer needed, we take reasonable steps to delete or de-identify it.

06Your choices

You can update available profile settings, disconnect integrations, revoke devices, and control which machines report to a workspace. Subject to applicable law, you may also request access, correction, export, deletion, restriction, or objection concerning your personal information.

Workspace owners and administrators control shared workspace records. If your account belongs to an organization, direct workspace-record requests to that organization first. We may need to verify identity and authority before completing a request.

Disconnecting an integration stops future ThreadOps access and provider events after the disconnection is processed, but it does not undo assignments, transitions, merges, or other changes already completed in the provider. Workspace retention settings and legal requirements may affect when synchronized records and release evidence are removed.

You may disable dispatch, revoke a worker, narrow its approved projects and runtimes, or cancel an eligible queued or running task. A cancellation request may not reverse file changes, provider usage, or other effects that occurred before execution stopped. Dispatch instructions, detailed results, logs, and artifacts follow the retention controls shown for that feature; limited lifecycle and audit records may remain longer.

07Security

We use administrative, technical, and organizational safeguards designed for the nature of the information we process. These include access controls, secret-handling boundaries, encrypted transport, credential protection, rate limits, and monitoring. No system can guarantee absolute security.

You are responsible for protecting your account credentials, limiting read and write integration scopes, reviewing workspace membership, approving only appropriate workers, repositories, runtimes, trust modes, and recipients, and promptly reporting suspected unauthorized access to Agnes Riley, the ThreadOps operator, through the public contact method through the private ThreadOps request form.

08International use

ThreadOps and its providers may process information in countries other than the one where you live. Where required, we use recognized transfer mechanisms and contractual protections. Local privacy rights may vary by jurisdiction.

09Children

The Service is intended for professional software work and is not directed to children under 16. If you believe a child has provided personal information through ThreadOps, contact the operator through the private ThreadOps request form.

10Changes and contact

We may update this policy as the Service or legal requirements change. We will post the revised version here, update its effective date, and provide additional notice when required.

ThreadOps is operated by Agnes Riley. For privacy questions or requests, use the private ThreadOps request form.