When Claude Code Still Writes Stale Code With Context7 Installed — Verifying the Injection Actually Worked

Check "did it work" mechanically, every time

Eyeballing code and judging "this looks current" is unreliable. I settled on using an API that's known to have changed after the training cutoff as a litmus test. The Next.js 15 change where params became a Promise is a perfect one. If the injection worked, you'll see Promise< and use(; if it didn't, you'll see synchronous access.

I keep a small harness that checks generated files for this difference automatically.

// scripts/verify-fresh.mjs
// Verifies a generated Next.js page follows the v15 params contract.
// A litmus test that mechanically rejects leftover old patterns.
import { readFileSync } from 'node:fs';
 
const file = process.argv[2];
if (!file) {
  console.error('usage: node verify-fresh.mjs <generated file>');
  process.exit(2);
}
 
const src = readFileSync(file, 'utf8');
const usesParams = /params/.test(src);
 
if (!usesParams) {
  console.log('skip: file does not deal with params');
  process.exit(0);
}
 
// In v15 params is a Promise; it should be resolved with await or React's use().
const isFresh = /params\s*:\s*Promise</.test(src)
  && /(await\s+params|use\(\s*params\s*\))/.test(src);
 
if (isFresh) {
  console.log('ok: follows the Next.js 15 params contract');
  process.exit(0);
}
 
console.error('NG: old App Router (synchronous params) pattern remains');
console.error('  -> regenerate with an explicit library ID and version');
process.exit(1);

Run it as node scripts/verify-fresh.mjs app/items/[id]/page.tsx and decide on the exit code. Wired into CI, it stops a stale generation from quietly getting merged. Ideally you write a litmus test per library, but starting with the single library you get wrong most often is enough. I keep the same kind of check for Prisma relation definitions too.

The key is to aim the check at "is an old pattern still here," not "does the code run." Whether it runs is another test's job; here you only care about freshness.

When you hit a library Context7 doesn't cover

Context7 covers many libraries, but niche packages and very recent releases can be unsupported. When that happens Context7 returns a near-empty result, Claude falls back to trained knowledge, and — again — quietly writes stale code.

Assume non-coverage and keep a two-stage approach. If resolve-library-id doesn't land, hand it the official documentation directly. In Claude Code you can use the WebFetch-style tools, or pull the docs locally and pass them as a file.

This library may not be in Context7.
If it isn't found, write code based only on the official docs I paste below.
Do not fill in the API from your trained memory.

[paste the relevant section of the official docs here]

That one line — "do not fill in from your trained memory" — quietly matters. Without it, Claude mixes the pasted docs with its memory, and you end up with code that's only partly stale.

Write a freshness rule in CLAUDE.md, and scope it tightly

Typing use context7 every time doesn't last. A rule in the project's CLAUDE.md makes it apply automatically when you write code for the target libraries. But don't make every library a target. The docs Context7 returns consume tokens and crowd the context window. Forcing a pull for stable libraries too eats the context you actually need for the code, and quality drops instead.

Scope it to "fast-moving and easy to get wrong." Here's how I draw the line.

Write that scoping straight into CLAUDE.md.

## Code generation freshness rule
 
When writing code for the following libraries, always consult the latest docs via context7.
Targets: Next.js, React, Tailwind CSS, Prisma, Drizzle ORM
 
After consulting, self-check that no old-version patterns remain in the output.
Do not use context7 for stable libraries outside this list (to save context).

Making the scope explicit keeps your judgment steady when you move across repositories. I run four sites on the same policy, so I keep these few lines as a template at the top of each CLAUDE.md.

After a few weeks, where it settled

The biggest change after adopting Context7 was no longer entertaining that small "is this current?" doubt every time I received code. But I've come to feel that's not because I installed it — it's because I added a way to confirm the injection worked. In the first few days, with the MCP merely installed, I actually let more stale code through, believing it was working — worse than before.

Documentation-injection MCPs are hard to trust precisely because their effect is hard to see; they only become trustworthy paired with verification. Log the calls with a hook, mechanically check freshness with a litmus test, and prepare by hand for unsupported libraries. Only after putting those three in place did the tool finally feel grounded.

For your next step, pick the one library you've most recently been handed stale code for, and write a single litmus check around what changed in its API. Rather than chasing an all-purpose verifier, putting one check where it hurts most is what makes the practice stick.