Every modern developer has felt the uncanny sensation of GitHub Copilot anticipating a logic jump before they even type the first character. It feels like the AI is reading the developer's mind, but in reality, it is reading the workspace. As these tools evolve from simple autocomplete plugins into sophisticated agents that understand entire codebases, a critical question emerges regarding where the boundary lies between local privacy and cloud-based context. The curiosity about how Copilot actually gathers this intelligence leads to a deep dive into the network traffic and local storage of the VS Code extension.
The Plumbing of Copilot's Network Stack
Because VS Code is built on the Electron framework, it shares the Chromium network stack, which provides a predictable surface for traffic analysis. To peel back the curtain, researchers utilize `mitmproxy` to establish a Man-in-the-Middle (MitM) position between the client and the GitHub servers. This requires a specific configuration within VS Code to force the extension's traffic through the proxy. By setting the `Http Proxy` to `http://localhost:8080`, disabling `Http Proxy Strict SSL`, and setting `Http: Proxy Support` to `override`, the encrypted TLS traffic is decrypted and captured for inspection.
Once the environment is bootstrapped, Copilot follows a rigid sequence of requests to establish its operational state. The process begins with authentication and session verification, followed by a query for configuration and policy settings. It then checks the MCP (Model Context Protocol) registry before finally loading the repository context. The model discovery phase is particularly revealing, as it occurs in two distinct stages. First, the client hits the `/models` endpoint to retrieve a general list of models available to the user's specific account and plan. Subsequently, it calls `/agents/swe/models` to identify models specifically optimized for Software Engineering (SWE) agent tasks, indicating a tiered architecture where different models are swapped based on the complexity of the engineering task.
When a user sends a message, the system does not immediately route the prompt to a generative model. Instead, it first hits the `/models/session/intent` endpoint. This acts as a traffic controller, classifying the user's prompt into categories such as code-gen, debugging, reasoning, or tool-use. This intent classification determines the routing logic, ensuring that a complex reasoning task is handled by a high-parameter model while a simple code completion is routed to a faster, more efficient one.
The SQLite Vault and the Sliding Window Leak
While the network traffic reveals the routing, the local file system reveals the memory. Copilot manages its local state through a SQLite database named `session-store.db`. The system interacts with this database using a tool called `session_store_sql`, which executes queries to retrieve and store interaction history. A critical finding here is that the `user_message` and `assistant_response` columns store data in plain text. The LLM does not possess an innate knowledge of the database schema; instead, it performs a form of introspection. If an initial query fails, the model queries the schema metadata to understand the table definitions before attempting to extract the required data.
This architectural choice extends to how the AI maintains context during inline completions. The logic defined in `recentEdits.tsx` implements a sliding window mechanism to decide what code snippets are sent to the server. By default, this window captures up to 20 files, 8 edit summaries, and 3 lines of surrounding context for every change. This is designed to give the model a "short-term memory" of the developer's recent movements across the project.
However, this sliding window creates a significant security blind spot. Many developers believe that disabling Copilot for a specific sensitive file, such as a `.env` file containing API keys, ensures that the data stays local. The reality is more complex. If a developer is editing a non-excluded file, such as `pyproject.toml`, and the `.env` file falls within the sliding window of recent edits, the contents of the `.env` file are bundled into the API request and transmitted to the cloud. The system prioritizes the continuity of the editing session over the exclusion rules of individual files.
Currently, for users on individual plans, there is no native integration with `.gitignore` or automated exclusion rules based on file extensions to prevent this. These granular controls are locked behind the Business and Enterprise plans, where administrators can define a repository policy to strictly govern which files are allowed to leave the local environment. The lack of these protections for individual users means that sensitive credentials can be leaked to the model's context window without the user ever explicitly opening the sensitive file during the current session.
As AI coding tools transition from stateless chatbots to stateful systems that integrate workspaces, edit histories, and local databases, the primary concern for developers must shift. The focus is no longer just on the performance of the model, but on the design of the harness that defines the boundary of context collection. Maintaining data confidentiality now requires a proactive strategy to manage what the sliding window sees, rather than relying on simple file-level toggles.
