What Your AI Assistant Sends Out: Traffic Audit with mitmproxy

On August 11, 2026, a breakdown circulated on Hacker News that everyone who uses an AI assistant in their working IDE should read: a researcher set up VS Code with GitHub Copilot behind an intercepting proxy and examined what exactly was sent to the servers. It turned out that significantly more than just the line you are typing is included in the request — including the contents of the open .env file in plain text.

The good news: anyone can verify this, and not just with Copilot. Below is a working guide on how to set up an audit of your assistant's traffic in 20–30 minutes, what to look for in intercepted requests, and what limitations exist with the built-in file exclusion mechanisms.

Why do it yourself

The vendor's documentation describes policy, not the actual behavior of the client. There is a vast difference between "we do not use your code for training" and "the client does not send your code to the server": to generate a suggestion, the model must receive context, and the only question is how broadly the client collects this context.

An audit is necessary if you:

• work under an NDA or with clients' personal data and need to know what goes beyond the perimeter;
• store secrets, environment configurations, internal addresses, and tokens in your repository;
• are responsible for compliance in your team and need not just a screenshot of the settings but a log of actual requests;
• simply want to understand why the assistant suddenly "knows" about a file you haven't opened.

What was found in Copilot's traffic

The breakdown in question relied on the classic mitmproxy: VS Code was directed to a local proxy on port 8080, and strict certificate verification was disabled. Key findings:

• The context is broader than a single file. During inline completions, the client collects up to 20 files, 8 summaries of recent edits, and 3 lines of context around each change, plus the full text of the current file and recently edited files as diffs.
• Secrets are not masked. In the request body, the prompt field contained a string like TEST_ENV_VAR_SECRET="mysecretenvvar" — meaning environment variables from the open file were sent as plain text.
• The local database is also exposed. The session-store.db file stores user_message and assistant_response without encryption or editing: it contained tokens, cloud provider keys, and passwords from connection strings that you once pasted into the chat.
• Service calls. Besides the actual completions, the client calls /models, /agents/swe/models, /models/session/intent, and GitHub OAuth endpoints — these provide a clear view of how the assistant classifies your request even before generating a response.

It is also important to remember: the client sends the URL of the current repository to the server to obtain the applicable exclusion policy. This fact is harmless in itself, but it means that the composition of your working tree is also a signal.

Step-by-step: setting up interception

1. Install mitmproxy and run it. The web interface is sufficient: mitmweb. By default, the proxy listens on port 8080, and the console opens in the browser. For CI and long sessions, mitmdump is more convenient.
2. Install the root certificate. Upon the first launch, mitmproxy creates a CA in the ~/.mitmproxy directory (the file mitmproxy-ca-cert.cer). It needs to be added to trusted certificates — otherwise, the client will terminate the TLS connection. For the duration of the audit, user-level trust is sufficient; afterwards, remove the certificate and do not leave a foreign CA in the system "just in case."
3. Select the interception mode. There are three modes, and the right choice saves an hour of hassle:
   • regular — a standard proxy, the client is configured explicitly. The most predictable option.
   • local — transparent interception of applications on the same machine, without modifying program settings: mitmproxy --mode local:Code will catch only the VS Code process, --mode local:42 — the process with the specified PID, --mode local:!curl — everything except curl. This is the best way to listen to an assistant that does not have proxy settings.
   • upstream — a chain where your own proxy is behind mitmproxy: mitmdump --mode upstream:http://host:8081, and login and password are set with the option --set upstream_auth=user:pass.
4. Direct the IDE to the proxy (for regular mode). In VS Code in settings.json:
   • "http.proxy": "http://127.0.0.1:8080"
   • "http.proxySupport": "override"
   • "http.proxyStrictSSL": false — only for the duration of the audit. This flag completely disables certificate verification and should not be left in the working config.
5. Address the certificate issue properly. The Copilot extension runs on Node, so the correct approach is not to disable verification but to compile a PEM with root CAs plus the mitmproxy certificate and specify it through the environment variable NODE_EXTRA_CA_CERTS. The IDE needs to be restarted: the variable is read at process startup.
6. Write the stream to a file. Watching in real-time is useless — there are dozens of requests per minute. Enable --set save_stream_file=flows.dump, and to avoid collecting everything, limit the sample through --set save_stream_filter=.... Later, the file can be analyzed offline.
7. Search by request body, not by URL. A practical trick: place a canary file with a unique string (for example, CANARY_9f3c_DO_NOT_SEND) in a test repository, open it in the editor, work in a neighboring file — and then search for the canary in the intercepted bodies. This way, you will see not the theoretical but the actual radius of context collection specifically for your version of the client.

Pitfalls

The license may block interception. On corporate plans, Copilot returns an error like "Your current Copilot license does not support proxy connections with self-signed certificates." This is not a proxy bug — the client intentionally refuses to work through a self-signed CA. It can be resolved with a trusted certificate at the system level or by building a PEM for Node; if the organization's policy prohibits this, the audit will need to be coordinated with the admin rather than circumvented.

Pinning and QUIC. Some clients operate over HTTP/3 on top of QUIC, which a regular proxy will not see. If after enabling interception the application "works, but the log is empty" — the reason is almost always this: block UDP/443 for the test process, and the client will revert to HTTP/2.

Telemetry and payload go different ways. Do not conclude "nothing is sent" based on one endpoint: look at the entire list of hosts the process accesses, not just the one mentioned in the documentation.

Legal framework. You can intercept traffic on your machine and on your account. Listening to someone else's work laptop without the owner's knowledge is a different story, and no "security" justifies it.

What to do with the results

If the audit shows that extra files are included in the requests, the built-in tools look like this — and each has a significant limitation.

• Content exclusion. An official GitHub mechanism that prevents Copilot from using specified paths. Available only on Business and Enterprise plans, configured by the administrator in Copilot settings, supported in VS Code, Visual Studio, and JetBrains; in Xcode, Eclipse, and Vim/Neovim — only for inline suggestions.
• The main gap is agent mode. Documentation explicitly states that exclusions are not supported in Edit and Agent modes in Copilot Chat, as well as in Copilot CLI. This means that exactly where the assistant navigates through files, reads configurations, and executes commands, platform filtering is not applied. If you rely on content exclusion as the only barrier — there is no barrier in agent mode.
• .gitignore does not protect. A common misconception: exclusion from the Git index does not mean exclusion from the assistant's context.
• Organizational minimum. Secrets should go into a secrets manager, not into a .env file next to the code; the assistant's chat is not a place for inserting connection strings; the local history database should be cleaned just as you clean your shell history.

Where does the proxy fit in and why do you need it

Interception has practical applications. First, the upstream mode allows you to route all assistant traffic through a controlled outbound node: you can see the requests while managing the address they are sent from. This is necessary when the assistant's API is not accessible from your region or when corporate policy requires a fixed outgoing IP — for such scenarios, stable data center proxies with a permanent address are suitable.

Second, the same setup will be useful for debugging automation: when the AI agent navigates websites on its own, interception shows what headers it actually sends and what protections catch it. We discussed this combination in our article about proxies for AI agents on Playwright and MCP — there, we talked about choosing the type of address for agent scenarios where a residential IP is needed, not a server one.

If you haven't set up mitmproxy before, start with the basic HTTPS interception setup — it is detailed in our guide on intercepting traffic with mitmproxy, and then build on top of it with local and upstream modes.

Conclusion

Auditing AI assistant traffic is not paranoia, but normal engineering hygiene that takes one evening and is done once. The Copilot breakdown showed a clear picture: the client collects context broadly, secrets are included in this context alongside the code, local history is stored in plain text, and built-in exclusions do not work precisely in the most dangerous mode — agent mode.

Check the traffic, not the documentation. Set up mitmproxy in local mode, place a canary in the repository, collect the stream to a file, and see for yourself what is leaving your machine. The next step is simple: either you consciously accept this volume of transmission, or you move secrets out of the working tree before they are seen by a foreign server.