Fixing Roo Code "Context Window Exceeded" Errors on Large Monorepos

The Problem

Roo Code works great on small-to-medium projects, but the moment it's pointed at a large monorepo (multiple packages, a big history, generated files, or several unrelated apps sharing one repo root), tasks start failing with a context window exceeded error, or the model's responses get visibly worse — it starts forgetting instructions from earlier in the same task, or references files that don't exist.

The root cause isn't that the task itself is too complex — it's that Roo Code is reading far more of the repository into context than the task actually needs, because nothing is telling it which parts of a large monorepo are relevant.

Why It Happens

No .rooignore, so everything is fair game

Without a .rooignore file, Roo Code's file-search and directory-listing tools will happily walk into build output directories, generated type definitions, lockfiles, vendored dependencies, or unrelated sibling packages — all of which eat context budget without adding anything useful to the task at hand.

Broad, unscoped requests on a multi-package repo

Asking a broad question ("find where auth is handled") on a monorepo with a dozen packages makes the agent search far more broadly than it would on a single-package repo, pulling in files from packages that have nothing to do with the actual task.

Long-running tasks accumulate tool-result bloat

A task that reads several large files early on, then continues for many more turns, keeps carrying that early content in context even after it's no longer relevant to what's being worked on right now, crowding out room for what actually matters later in the same task.

The Fix

1. Add a .rooignore scoped to what generated/vendored content actually exists

# .rooignore
node_modules/
dist/
build/
coverage/
*.lock
**/*.generated.ts
packages/*/dist/

This is the single highest-impact fix — it stops the agent from ever reading content that was never going to be relevant, rather than relying on it to be smart enough to skip those files itself every time.

2. Scope requests to the specific package or directory when you know it

Instead of "find where auth is handled," specify "find where auth is handled, inside packages/api" whenever you already know the rough location — this keeps the search tools from walking the entire monorepo tree on every broad question.

3. Break long tasks into smaller ones with a fresh context

If a task naturally splits into distinct phases (investigate, then implement, then verify), starting a new task for the implementation phase — carrying forward only a short written summary of what was found, not the full investigation transcript — keeps context usage proportional to what's actually being worked on.

4. Use a repo-level README or CLAUDE.md-style file to shortcut discovery

A short file describing the monorepo's package layout and where key functionality lives lets the agent jump straight to the right package on the first read, instead of exploring breadth-first across every package to build that same map from scratch on every new task.

Why This Works

None of this makes the underlying context window bigger — it reduces how much of it gets spent on content that was never going to help. .rooignore removes irrelevant files before they're ever read; package-scoped requests and repo-map files reduce how much exploration is needed to find the right place; and splitting long tasks stops old, no-longer-relevant content from crowding out what the current phase of work actually needs.

Conclusion

Context window exceeded errors on a large monorepo are almost never a sign the task is too big for the model — they're a sign the agent is reading far more of the repository than the task requires. A scoped .rooignore, package-specific requests, and splitting long tasks at natural phase boundaries fix the underlying cause instead of just working around the symptom.