Copilot Code Review and the 4,000 Character Limit

Here is a fun way to lose an afternoon: carefully write coding standards into your repository’s .github/copilot-instructions.md, request a Copilot code review on a pull request that violates several of them, and watch the review come back with cheerful comments about none of it.

The instructions were fine. The file was in the right place. The problem was quantity: my instructions file was many thousands of characters long, and at the time, Copilot code review read only the first 4,000 of them.

The documented limit

This was not undocumented behavior I had to reverse-engineer. GitHub’s documentation for Copilot code review carried an explicit note, which read^[1]:

Copilot code review only reads the first 4,000 characters of any custom instruction file. Any instructions beyond this limit will not affect the reviews generated by Copilot code review. This limit does not apply to Copilot Chat or Copilot cloud agent.

Read that second sentence again, because it describes a genuinely nasty failure mode: silent truncation. Nothing errors. Nothing warns. The review simply behaves as if the back half of your file does not exist, and unless you know about the limit, you will debug everything except the actual cause. You will rephrase rules, move files, question whether the feature works at all. The rules at the top of the file keep working the whole time, which makes the diagnosis harder, not easier: the feature is clearly reading something.

The part of the note that stung most: the limit applied only to code review. The same file, read by Copilot Chat or the cloud agent, was consumed in full. One file, three consumers, two reading budgets.

The limit has quietly left the docs

Before writing this post I went back to confirm the note, and it is gone. The current documentation for customizing Copilot code review^[2] describes the instruction file hierarchy – repository-wide instructions, AGENTS.md, path-specific .instructions.md files – with no character figure attached. The archived version with the 4,000-character note is preserved on the Wayback Machine^[1].

Maybe the limit was raised. Maybe it was removed entirely. Maybe it still exists at some other number and simply is no longer documented. From the outside, silent truncation with a documented number and silent truncation without one are difficult to tell apart, and that is precisely the point I want to make: you should write your instruction files as if a budget exists, because one always does. Context windows are finite. Products trim inputs. The trims are rarely announced, and vendor documentation changes faster than your instincts do. The 4,000-character note was unusual only in being written down.

What I changed, and kept

Getting burned by the limit forced structural changes to how I write instruction files, and every one of them still pays off regardless of what today’s limit is:

• Front-load review-critical rules. The rules I most want enforced in code review live in the first screenful of the file. If a consumer reads only the beginning, the beginning is what gets followed. Ordering by importance costs nothing and defends against every truncation, present and future.
• Move path-specific rules out of the main file. T-SQL formatting standards do not need to occupy budget when Copilot is reviewing a PowerShell script. Path-scoped .github/instructions/*.instructions.md files with applyTo frontmatter keep each review’s instruction load small and relevant^[3].
• Treat length as a cost, not an achievement. A long instructions file feels thorough. In a budgeted context it is a gamble that the important parts landed in the funded region. Every rule that is not earning its bytes is pushing a rule that would.
• Test with a canary. The fastest way to learn whether your instructions are being honored at all: put a cheap, unmistakable rule in the file (“start every review summary with the word ‘Verified'”), request a review, and look. GitHub’s own docs use “respond in Spanish” as their example instruction, which makes an excellent canary precisely because compliance is binary and instant to spot. Move the canary to the end of the file and you have a truncation detector.

The general lesson for DBAs

If you have spent years around SQL Server, you already have the right reflex; you just have not applied it here yet. We do not trust that a varchar will not truncate; we check the length. We do not trust that a maintenance script handles every edge; we read the guard clauses. AI tooling deserves the same posture: assume limits exist, assume they are silent, position the important content defensively, and build cheap detection into the workflow.

I wrote about the distribution side of instruction files in sharing Copilot instructions across repos and teams (where this limit gets a brief mention, and where “keep it under 4,000 characters” was the working rule), and about the broader compliance problem in getting your AI agent to actually follow your instructions.

Have you caught an AI tool silently ignoring part of your configuration? I want to hear the war story: comments below, or find me on Bluesky or LinkedIn.

References

1. Using GitHub Copilot code review (archived) – GitHub Docs via the Internet Archive Wayback Machine. The version of the documentation containing the 4,000-character note quoted above. ↩
2. Using GitHub Copilot code review – GitHub Docs. The current documentation, including the custom instructions section without the character limit note. ↩
3. Adding repository custom instructions for GitHub Copilot – GitHub Docs. Repository-wide and path-specific instruction file formats and locations. ↩