What Actually Gets Sent in the Context Window

AI code completion is not just about the line under your cursor. Every major assistant sends a context window β€” a chunk of code assembled from multiple sources β€” to a remote endpoint so the model can produce a relevant suggestion. Understanding what is in that chunk is non-negotiable before you let a tool touch a sensitive codebase.

At minimum, the payload includes the current file up to and around the cursor position. Beyond that, individual tools differ:

  • GitHub Copilot sends the current file content plus a selection of other recently open files (siblings in the same workspace directory). The official documentation calls these "neighboring files" and they are included to give the model more project context. The exact selection algorithm is not public.
  • Cursor operates with a configurable context strategy. Its Composer and Agent modes can ingest entire directory trees. When "Codebase Indexing" is on, Cursor builds a local embedding index and sends relevant chunks to its backend alongside your query.
  • Windsurf (Codeium) has a similar codebase-awareness feature called "Cascade". It indexes the local workspace, selects high-relevance chunks using its own retrieval logic, and appends them to the inference request.

The practical implication: opening a file that contains an AWS access key β€” even to quickly check a value β€” may pull that file into a neighboring-file context selection and transmit the credential to a third-party server.

The inference request itself is typically sent over TLS to the provider's API. The content is not meaningfully different from what you would send if you pasted code directly into a chat interface β€” the tool just automates that action thousands of times per session.

What Is Not Sent

Binary files, compiled artifacts, and files matching common ignore patterns (`.gitignore`, `.copilotignore`, `.cursorignore`) are generally excluded. But these exclusions rely on configuration that developers often don't set up deliberately.

Auditing What Your Tool Sends

You don't have to trust vendor documentation. Network-level inspection tells you exactly what is leaving your machine.

Capturing Requests with mitmproxy

Run a local MITM proxy, trust its certificate system-wide, and watch the traffic. For VS Code-based tools:

# Start mitmproxy with web UI mitmproxy --listen-port 8080 --web-port 8081 # Configure VS Code to use it # In settings.json: "http.proxy": "http://127.0.0.1:8080", "http.proxyStrictSSL": false # Trust the mitmproxy CA cert system-wide on macOS sudo security add-trusted-cert -d -r trustRoot \ -k /Library/Keychains/System.keychain ~/.mitmproxy/mitmproxy-ca-cert.pem

With this in place, every HTTP/S request from VS Code β€” including Copilot completion requests β€” is visible in the mitmproxy web UI at http://127.0.0.1:8081. You can see the full request body, which will contain the serialised context window.

What a Copilot Request Looks Like

A typical GitHub Copilot completion request is a POST to https://copilot-proxy.githubusercontent.com/v1/engines/copilot-codex/completions (the endpoint has changed over time). The JSON body includes a prompt field that contains the assembled context:

{ "prompt": "// path/to/neighboring-file.py\n... file content ...\n\n// path/to/current-file.py\n... current file up to cursor ...", "suffix": "... content after cursor ...", "max_tokens": 500, "temperature": 0, "top_p": 1, "n": 1, "stop": ["\n"] }

The neighboring-file content appears verbatim. If neighboring-file.py contains a hardcoded database password in a comment, that password is in the prompt field of this JSON body, in plaintext, transmitted to GitHub's infrastructure.

Cursor Network Inspection

Cursor wraps its own Electron shell. You can inspect its traffic with the same proxy approach, or launch Chromium's built-in DevTools via the Help menu. Cursor's AI requests typically go to api2.cursor.sh. The payload for Composer requests is larger and includes retrieval results from the local index.

GitHub Copilot Controls

Copilot has several knobs that enterprise and individual users can adjust.

The .copilotignore File

This file follows gitignore syntax and tells the extension which paths should never be included in context. Place it at the repository root:

# .copilotignore # Never send these to Copilot's servers .env .env.* secrets/ config/production.yml *.pem *.key infra/terraform/ internal/credentials/

Unlike .gitignore, .copilotignore does not affect whether files are tracked by git β€” it only controls Copilot's context assembly. You need both.

Telemetry Opt-Out

GitHub Copilot for Individuals includes a setting to opt out of using your code snippets to train future models. This is separate from the context-window transmission, which always happens (that's how inference works). The training opt-out is configurable at github.com/settings/copilot under "Allow GitHub to use my code snippets".

For organisations on Copilot Business or Copilot Enterprise, GitHub's contractual terms state that prompt and suggestion data is not used to train models. This is a policy control, not a technical one.

Content Exclusions via Policy

GitHub Copilot Business allows administrators to set organisation-level content exclusions β€” path patterns applied across all members. These are configured in the GitHub organisation settings under Copilot and propagate to all members' extensions within a few minutes.

# Example org-level content exclusion (configured in GitHub UI, expressed here as YAML) copilot_content_exclusions: - pattern: "**/.env" - pattern: "**/secrets/**" - pattern: "**/infra/terraform/**" - pattern: "**/config/production*"

Cursor and Windsurf Controls

Cursor Privacy Mode

Cursor has a "Privacy Mode" toggle in Settings > General. When enabled, the vendor commits to not storing code on their servers beyond the immediate inference request. This is again a policy control backed by their terms of service, not a technical guarantee verifiable from the client side.

More useful technically is the .cursorignore file, which follows the same gitignore syntax as .copilotignore. Files matching these patterns are excluded from Cursor's codebase indexing and from context assembly.

Disabling Codebase Indexing

In Cursor Settings > Features > Codebase Indexing, you can disable the feature entirely. This prevents Cursor from reading and embedding your entire working directory. Chat and Composer features will still send the current file and editor context, but they won't attach retrieved chunks from across the repo.

Disabling indexing is not a complete solution. Even without it, Cursor's Agent and Composer modes will read files from disk on demand during a session β€” including files you reference in prompts. Sensitive files must still be protected at the gitignore and filesystem level.

Windsurf / Codeium

Codeium (which powers Windsurf) offers an enterprise tier with self-hosting options and on-premises model deployment. For teams that need genuine air-gap assurance, the self-hosted Codeium Enterprise is the only configuration that keeps code off external servers. In cloud mode, the behaviour is similar to Cursor: a local index, retrieval-augmented context, transmitted to Codeium's inference servers.

Credential and Secret Exposure Patterns

The most consequential data-leakage incidents don't involve source code algorithms β€” they involve secrets that ended up in the context window by accident.

Secrets in Comments

A developer hardcodes a test API key in a comment while debugging, intending to remove it later:

def get_data(endpoint): # TODO: replace with env var, test key: sk-prod-xxxxxxxxxxxx client = APIClient(api_key="sk-prod-xxxxxxxxxxxx") return client.get(endpoint)

If this file is open and Copilot selects it as a neighboring file, the key appears in the inference request. Secret scanning on the provider side may or may not catch it.

Environment Files

VS Code often opens .env files for editing. Without explicit ignore rules, these can end up in context. A .env file with database credentials, JWT signing secrets, or third-party API keys is exactly the data you don't want on a third-party server.

Test Fixtures with Real Data

Test fixtures and golden files sometimes contain sanitised copies of production data that is not fully sanitised. JSON fixtures with user email addresses, internal system identifiers, or schema structures from internal APIs can carry proprietary information into the context window.

Detection approach: Run a secret scanner like trufflehog or gitleaks against your entire working directory β€” not just committed files. Any secret it finds in a tracked or untracked file is a candidate for accidental context transmission.

# Scan working directory for secrets (not just git history) trufflehog filesystem --directory=. --no-update # Or with gitleaks gitleaks detect --source=. --no-git

Enterprise Policy and Governance

For organisations where data residency and IP leakage are material concerns, informal developer guidance is not sufficient. You need enforceable policy.

Approved-Tool Lists

MDM (Mobile Device Management) or endpoint policy can block installation of unapproved VS Code extensions. On macOS with Jamf or on Windows with Intune, allowlists can be enforced at the extension level. This is blunt but effective for preventing shadow-IT AI tools.

Network Egress Filtering

Enterprise proxies can block or log traffic to known AI coding assistant endpoints. This gives security teams visibility without blocking legitimate tools. Known destinations to consider:

  • copilot-proxy.githubusercontent.com β€” GitHub Copilot inference
  • api2.cursor.sh β€” Cursor inference and sync
  • server.codeium.com β€” Codeium/Windsurf inference
  • *.openai.azure.com β€” Azure OpenAI (used by some enterprise configurations)

Logging these destinations without blocking lets you audit which developers are using which tools, quantify data volume transmitted, and detect any unapproved tools that aren't on the allowlist.

Data Classification Zones

Some organisations create network or machine segments where AI tools are disabled entirely β€” typically for the most sensitive repositories (cryptography, authentication, customer PII processing). Developers working in these zones use standard completions only, or work offline. This is operationally expensive but is the only technical guarantee short of self-hosted inference.

Network-Layer Controls

Even if you trust the vendor's privacy commitments, defence-in-depth suggests adding technical controls at the network layer.

DNS-Based Blocking

A split-DNS or DNS sinkhole can redirect known AI assistant endpoints to an internal server that returns connection refused. This is trivially bypassed by a developer who changes their DNS resolver, so it's a weak control β€” useful for audit rather than enforcement.

TLS Inspection Proxy

A corporate TLS inspection proxy (Zscaler, Netskope, Palo Alto Prisma) can decrypt, inspect, and re-encrypt egress traffic. This lets security teams see the actual content of inference requests β€” not just destination and volume. Content inspection policies can then alert on patterns that look like secrets or PII.

The tradeoff: TLS inspection proxies require installing a CA certificate on developer machines, which is standard in enterprise environments but creates its own trust concerns. It also adds latency to every request, which is noticeable for interactive AI completions.

Least-Privilege API Keys

If your organisation uses GitHub Copilot with an enterprise licence, generate scoped GitHub tokens for Copilot access rather than using personal access tokens with broad scope. If a token is transmitted in a request body (not typical, but possible in misconfigured setups), limiting its scope reduces blast radius.

Self-Hosted and Local Inference Alternatives

For teams where no data should leave the premises, local-inference alternatives have matured significantly.

Ollama with Continue

The Continue VS Code extension can connect to a local Ollama instance running code-focused models like DeepSeek Coder, Qwen2.5-Coder, or Code Llama. All inference happens on-device or on a local server. The quality gap vs. GPT-4 has narrowed substantially as open models have improved.

# Install Ollama and pull a coding model brew install ollama ollama pull qwen2.5-coder:7b # In Continue's config.json: { "models": [{ "title": "Qwen2.5-Coder", "provider": "ollama", "model": "qwen2.5-coder:7b" }] }

Self-Hosted Codeium Enterprise

Codeium Enterprise can be deployed on-premises with your own GPU infrastructure. This gives you the Windsurf UX with zero external data transmission. Model weights are provided by Codeium under a commercial licence.

AWS CodeWhisperer with VPC Endpoints

Amazon CodeWhisperer (now part of Amazon Q Developer) supports VPC endpoint configurations that keep traffic within your AWS VPC. For organisations already committed to AWS infrastructure, this provides a path to AI code assistance without data leaving the AWS boundary.

Local inference won't match frontier model quality today, but it's closing fast. For security-sensitive codebases, the trade-off is often worth it β€” especially when the risk isn't hypothetical, it's verified by network capture.

Evaluation Criteria

When evaluating any AI coding tool for sensitive environments, the questions that matter technically are:

  • What is the exact scope of the context window? Which files, how selected, how large?
  • Is the context stored server-side after inference? For how long? Under what access controls?
  • Is there a technically enforceable data boundary (VPC endpoint, on-prem deployment) or only a contractual one?
  • Can context scope be narrowed through configuration, and is that configuration enforceable via policy?
  • What audit logging exists for queries sent and responses received?

Vendor answers to these questions vary significantly. "We don't train on your data" and "your data never leaves your infrastructure" are different claims entirely β€” only the second one offers meaningful technical protection.