How GitHub Copilot Reads Your Code Context

HubAI AsiaCompare & Review the Best AI Tools

Copilot reads 20 files you never opened — and that’s exactly how it knows what to suggest next. Most developers assume GitHub Copilot only looks at the file they’re editing, but behind the scenes, it’s been quietly scanning tabs, imports, and repository metadata for years. Understanding how Copilot assembles its context window is the difference between getting generic boilerplate and surgical, project-specific completions.

Step 1: The IDE Extension Captures Your Cursor Position

Everything starts the moment you stop typing. The Copilot VS Code extension (or JetBrains plugin) captures your cursor’s exact position in the active file and splits the surrounding code into two chunks: the prefix — everything above and before the cursor — and the suffix — everything below and after it. This prefix/suffix split is critical because Copilot uses the prefix to predict what comes next and the suffix to understand what must remain consistent below the insertion point.

The extension doesn’t send your entire file. It trims to a token budget, keeping the code immediately surrounding the cursor and discarding distant regions that are less relevant. If you’re editing a 2,000-line file but your cursor is on line 1,850, Copilot gets the bottom portion — not the imports at the top.

Step 2: Neighboring Tabs Ranks Your Open Files

Here’s where it gets interesting. The extension scans every tab you’ve opened in the last 7 minutes — up to 20 files — and ranks them using a Jaccard similarity coefficient that compares imported modules, function names, and class definitions across files. This algorithm is called Neighboring Tabs, and it’s the reason keeping relevant files open dramatically improves Copilot’s suggestions.

If you’re writing a React component and have utils/api.ts and types/user.ts open in other tabs, Copilot detects the shared imports and variable names, bumps those files’ priority, and uses their contents to generate completions that actually reference your project’s types and API helpers instead of inventing generic ones.

“GitHub Copilot’s context window expanded from 2,048 tokens in 2021 to 8,000 tokens by mid-2023, allowing it to process approximately 6,000 lines of code simultaneously”

Step 3: The Tokenizer Allocates the Context Budget

Once the relevant files are ranked, a BPE (Byte Pair Encoding) tokenizer converts everything into tokens. The budget is strict: 2,048 tokens are reserved for the current file surrounding the cursor position. The remaining tokens — out of the total 8,000-token context window — are distributed among the top-ranked neighboring files based on their similarity scores.

This means if you have 10 files open but only 3 share meaningful symbols with your current file, those 3 get the lion’s share of the token budget. Files with no overlapping identifiers get nothing. It’s a zero-sum allocation, and relevance is the currency.

Step 4: The Semantic Ranker Scores Repository Metadata

Beyond open tabs, Copilot also pulls in repository-level context. The semantic ranker evaluates files like README.md, package.json, and configuration files, scoring them for relevance. GitHub introduced a feature in February 2023 that gives README.md 3x priority weight compared to regular code files when generating suggestions.

This is why well-documented repositories get better Copilot suggestions. If your README clearly describes the project’s architecture and conventions, Copilot reads that and factors it into its completions. A one-line README gives Copilot almost nothing to work with at this layer.

The ranker then selects the top 3–5 files that share variable names, class definitions, or imported modules with the current file, and prepares them for inclusion in the final prompt.

Step 5: The Prompt Constructor Builds the Hierarchy

With the ranked files selected, the prompt constructor assembles them into a hierarchical structure. File paths are inserted as comments at the top of each snippet so the model knows which file it’s reading. Then the code snippets are inserted in descending priority order — the most relevant file first, the least relevant last.

The final prompt looks roughly like this:

• System instructions — telling the model it’s a code completion assistant
• Current file — prefix up to cursor, then suffix below cursor
• Neighboring file 1 — with filepath comment header
• Neighboring file 2 — with filepath comment header
• Repository metadata — README, package.json excerpts

This ordering matters. The model pays more attention to tokens at the beginning of the prompt (a well-documented phenomenon in transformer attention), so the most relevant context gets the most influential position.

Step 6: The Prompt Is Compressed and Transmitted

The assembled prompt gets compressed using a custom encoding scheme before being transmitted via HTTPS to GitHub’s Azure-hosted inference servers. Compression reduces bandwidth costs and latency — critical when you’re sending code context on every keystroke pause (typically after 300ms of inactivity).

GitHub runs Copilot’s inference on Microsoft Azure infrastructure, which means the data stays within Azure’s network boundaries. The transmission is encrypted in transit, but the key question for many teams is: what happens to the code after inference? GitHub’s current policy states that code snippets are not stored or used for training beyond a short retention window for abuse monitoring, but enterprise customers can opt out of even that.

Step 7: The Model Generates Multiple Completions

The core model behind Copilot — a descendant of OpenAI’s Codex, which was trained on 159 gigabytes of Python code from 54 million GitHub repositories — processes the prompt through billions of parameters. It doesn’t generate a single suggestion; it generates multiple completion candidates, each with an associated probability score.

These candidates are generated using nucleus sampling (top-p), which allows the model to explore diverse completion paths while staying within a high-probability region. The result is typically 3–5 candidate completions ranked by confidence, from which Copilot selects the best ones to show you.

Step 8: Post-Processing Filters Exact Training Matches

Before any suggestion reaches your editor, a post-processing filter runs a 256-bit hash comparison against a database of known training data. If a completion exactly matches code from the training corpus, it’s filtered out. This is GitHub’s primary defense against verbatim reproduction of copyrighted code — the same mechanism that triggered the 2022 class-action lawsuit alleging Copilot reproduced open-source licenses without attribution.

The filter isn’t perfect. It catches exact matches but not paraphrased or structurally similar code. After filtering, the top 3 unique completions are returned to your IDE, ranked by confidence score. You see the highest-confidence one as a gray ghost suggestion; the others are accessible via the Copilot suggestions panel.

How to Get Better Suggestions From Copilot

Understanding the context pipeline gives you practical levers to improve Copilot’s output:

• Keep relevant files open. Neighboring Tabs only scans files open in the last 7 minutes. If you’re working on a feature that spans 4 files, keep all 4 open — even minimized.
• Write a real README. The 3x priority weight on README.md is a free boost. Describe your architecture, naming conventions, and patterns.
• Use consistent naming. The Jaccard similarity scorer matches on variable names and imports. If your API client is called apiClient everywhere, Copilot picks up the shared symbol. If you call it client in one file and api in another, the similarity score drops.
• Add a .copilotignore file. Just like .gitignore, this tells Copilot to skip certain files and directories. Use it to exclude generated code, large data files, and anything that would waste your token budget on irrelevant context.

The Privacy Question Nobody Asks

But what happens when Copilot finds your secret API keys in those 20 files?

The Neighboring Tabs algorithm doesn’t distinguish between code and credentials. If you have a .env file open or a config file containing API keys, those tokens are included in the prompt sent to GitHub’s servers. GitHub’s official guidance is to use .copilotignore and secret scanning tools — but most developers never configure either. The responsibility falls on you to ensure that Copilot’s voracious appetite for context doesn’t end up feeding your production secrets to an inference server you don’t control.