Context Pilot / Trust Center
Context Pilot / Trust Center / Data Privacy

Data Privacy

Last updated: June 22, 2026
Policy DP-2.0

This document describes how Context Pilot handles data throughout its lifecycle, including classification, storage, transmission, and retention. Context Pilot's privacy posture is defined by a fundamental architectural property: we do not operate data-receiving infrastructure, making data collection structurally impossible.

1. Data Classification

The following table categorizes all data types processed by Context Pilot, their storage locations, and transmission characteristics.

Data Category Storage Location Transmission Classification
Source code context Assembled in-memory during active sessions To configured LLM provider Confidential
Conversation history .context-pilot/ — YAML files Local only Internal
Entity database .context-pilot/shared/entities/ — SQLite Local only Internal
Memory store .context-pilot/ — YAML files Local only Internal
Log entries .context-pilot/ — YAML files Local only Internal
Search index Meilisearch on 127.0.0.1 (local sidecar) Local only Internal
Text embeddings Indexed locally in Meilisearch To Voyage AI (if configured) Confidential
API credentials .env file or environment variables To designated provider only Secret
Search queries Not persisted To Brave Search (if configured) Internal
OCR documents Cached at ~/.context-pilot/ocr-cache/ To Datalab (if configured) Confidential

2. Privacy-by-Design Controls

The following controls are enforced at the architectural level. They are not configurable options — they are structural properties of the system design.

No data collection infrastructure

Context Pilot does not operate servers, databases, APIs, or any other infrastructure capable of receiving user data. The organization has no technical ability to access, collect, or process user data. This is a structural guarantee, not a policy commitment.

No telemetry or analytics

The software contains no telemetry endpoints, analytics SDKs, crash reporting services, feature flags, or usage tracking mechanisms. This can be independently verified by auditing the open-source codebase for any HTTP call not attributable to a user-configured provider.

Credential isolation

API keys are stored in local files (.env) or system environment variables. Each credential is routed exclusively to its designated provider endpoint. No credential aggregation, cross-provider sharing, or centralized key management exists.

Opt-in external services

Every third-party service integration is explicitly opt-in. The operator must provide an API key to enable each service. No service communicates with external endpoints without explicit operator configuration.

3. Data Retention Policy

As all data resides on the operator's local filesystem, retention is fully under operator control. Context Pilot does not enforce retention schedules — the operator manages data lifecycle through standard filesystem operations.

Local Data

Operator-Controlled

All persistent data under .context-pilot/ can be deleted, archived, or backed up by the operator at any time using standard filesystem tools. No special tooling or API calls are required for data deletion.

  • Conversation history: YAML files, deletable individually or in bulk
  • Entity database: SQLite file, deletable or exportable
  • Memory and log stores: YAML files, deletable individually
  • Search index: Meilisearch data directory, deletable for full re-index
  • OCR cache: File-based cache, deletable for space reclamation

Provider-Transmitted Data

Provider-Dependent

Data transmitted to third-party providers (LLM inference requests, search queries, embedding vectors) is subject to each provider's own data retention and processing policies. Context Pilot does not control post-transmission data handling. Operators should review their provider agreements independently.

  • Anthropic API: Does not train on API data by default (see Anthropic's data policy)
  • OpenAI API: Configurable data retention (see OpenAI's data policy)
  • Other providers: Refer to each provider's published data processing terms

4. Data Subject Rights

Context Pilot's local-first architecture simplifies data subject rights compliance. Because no personal data is collected by Context Pilot, the following rights are satisfied by architecture.

Right Applicability Mechanism
Right of Access All data is on the operator's local filesystem Direct filesystem access
Right to Erasure Operator has full control over local data Delete .context-pilot/ directory
Right to Portability Data stored in standard formats (YAML, SQLite) Copy/archive the project directory
Right to Restrict Processing Operator controls all processing locally Disable specific modules or stop the application
Right to Object No automated decision-making by Context Pilot Not applicable — all actions are user-initiated

5. Frequently Asked Questions

No. Context Pilot does not operate servers. The software runs entirely on your workstation. The only network calls are to LLM providers you configure with your own API keys. You can verify this by auditing the open-source codebase.
Your LLM provider receives the assembled conversation context (system prompt, tool definitions, conversation messages, and code context from open files) for each inference request. The specific data transmitted depends on which files you have open and what context the AI is working with. Provider data handling is governed by your agreement with that provider.
Core functionality works offline. File management, local search (keyword-based), memory systems, entity databases, and conversation management do not require network access. LLM inference requires API connectivity to your configured provider. Semantic search requires the Voyage AI embedding service. Web search and scraping require their respective services. All external services are opt-in.
No. There is no telemetry to disable because none exists. The software does not contain analytics endpoints, tracking pixels, crash reporters, or phone-home mechanisms. This is verifiable in the source code.
Delete the .context-pilot/ directory in your project root. For global configuration, delete ~/.context-pilot/. These are the only two locations where Context Pilot writes persistent data. No external cleanup is required on our side because we hold no data.
Context Pilot transmits data only to explicitly configured API providers. All outbound connections are enumerable and predictable (see the Subprocessor Register). If your DLP policy restricts data transmission to specific endpoints, you can verify compliance by reviewing the configured provider list. No undocumented or hidden network calls exist. For maximum control, you can operate Context Pilot with only a locally-hosted LLM provider, achieving zero data egress.
Context Pilot itself does not transmit data to any Context Pilot-operated infrastructure. However, it does transmit code context to your configured LLM provider for inference. Whether this is acceptable depends on your LLM provider's data handling terms and your organization's classification requirements. For highest sensitivity, consider using a locally-hosted LLM (via an OpenAI-compatible API endpoint) to keep all data on-premises.
No. Context Pilot does not collect, process, or store biometric data, personally identifiable information (PII), or any form of personal data. The only "user data" that exists is the operator's own project files, which Context Pilot reads (with filesystem-level permissions) to provide coding assistance. Context Pilot has no concept of user identity, user accounts, or user profiles.

6. Cookie & Tracking Policy

Context Pilot has no cookie or tracking infrastructure. This section exists to provide a definitive, auditable answer for compliance questionnaires.

Zero cookies

Context Pilot does not set, read, or transmit HTTP cookies. The orchestration backend does not issue Set-Cookie headers. No session cookies, authentication cookies, tracking cookies, or third-party cookies exist in the application.

Zero tracking pixels

No tracking pixels, web beacons, fingerprinting scripts, or third-party analytics SDKs are included in any part of the application. The web frontend loads only first-party JavaScript from the local development server.

No advertising identifiers

No advertising IDs, device fingerprints, Google Analytics, Mixpanel, Amplitude, Segment, Heap, Hotjar, FullStory, or equivalent services are integrated. No consent banner is needed because there is nothing to consent to.

Local storage usage

The web frontend uses the browser's localStorage API for user preferences only (active view, active agent, thread selection, draft composer text). This data never leaves the browser and is fully controlled by the operator. It can be cleared via standard browser developer tools at any time.

7. International Data Transfers

Context Pilot's local-first architecture means no data crosses international borders through Context Pilot infrastructure. However, operator-configured API integrations may involve cross-border data transfers.

Context Pilot Infrastructure

No Transfer

Context Pilot does not operate servers in any jurisdiction. All data processing occurs on the operator's workstation in the operator's jurisdiction. No data crosses borders through Context Pilot-controlled infrastructure because no such infrastructure exists.

Third-Party Provider Transfers

Operator Responsibility

When the operator configures API integrations (LLM providers, search, OCR), data may be transmitted to servers in the provider's jurisdiction. The operator is responsible for evaluating the data transfer implications:

  • Anthropic: US-based. Processes API data in the United States. See Anthropic's privacy policy for SCCs and adequacy measures.
  • OpenAI: US-based. Data processed in the United States. Enterprise agreements may include EU data residency. See OpenAI's data policy.
  • Google AI: Global infrastructure. Data processing location depends on the operator's Google Cloud configuration.
  • Mistral AI: EU-based (Paris, France). Data processed within the European Union.
  • Brave Search: US-based. Search queries processed in the United States.
  • Voyage AI: US-based. Text chunks processed for embedding generation.

GDPR Transfer Mechanisms

Operators subject to GDPR who transmit data to non-EU providers should verify that their provider offers appropriate transfer mechanisms: Standard Contractual Clauses (SCCs), adequacy decisions, or Binding Corporate Rules (BCRs). Context Pilot cannot negotiate or enforce these mechanisms on behalf of operators, as it is not a party to the data processing relationship.

8. Data Processing Agreement Framework

Context Pilot's architecture fundamentally differs from cloud SaaS products. This section addresses the applicability of Data Processing Agreements.

DPA Applicability Assessment

A Data Processing Agreement (DPA) is a contractual arrangement between a data controller and a data processor. Context Pilot does not process data on behalf of operators — it is software that runs on the operator's own infrastructure. Context Pilot's legal relationship to the operator is that of a software licensor, not a data processor. Therefore:

  • A DPA between the operator and Context Pilot is not applicable — no data is processed on our infrastructure
  • DPAs between the operator and their configured API providers (Anthropic, OpenAI, etc.) may be required depending on the operator's regulatory obligations
  • The operator should evaluate each provider's DPA independently based on their use case and jurisdiction

Provider DPA Availability

Provider DPA Available Standard Terms
Anthropic Yes (enterprise agreements) Terms of Service
OpenAI Yes (DPA available on request) Terms of Use
Google AI Yes (Google Cloud DPA) Service Terms
Mistral AI Yes (EU-based, GDPR-native) Terms of Service
Brave Search Privacy-focused by design Privacy Policy
Voyage AI Contact provider voyageai.com