Cody Sourcegraph Indexing Failed: Fix Monorepo Workspace Errors

April 25, 2026 · Editorial Team · 6 min read · cody troubleshooting error-fix

You've opened a large monorepo in VS Code, Cody is installed and connected to your Sourcegraph instance, and then you see it: "Indexing failed" in the Cody sidebar, or "Context unavailable: indexing error," or the more cryptic variant where the chat works but every response says it has no codebase context. You ask Cody about your authentication service and it gives you a generic answer with no reference to your actual code. The whole point of Cody in a monorepo is that it understands your specific codebase, and "indexing failed" means it doesn't. The error message rarely tells you which workspace failed, why it failed, or how to fix it.

What this error actually means

Cody indexes your codebase to build the context it needs for accurate, codebase-aware responses. In a single workspace this is straightforward: Cody walks your files, creates embeddings or a search index, and stores it. In a monorepo with multiple workspaces (as in a VS Code multi-root workspace, or a Turborepo with 30 packages), Cody has to index each workspace root separately and then merge the results.

The "indexing failed" error means one or more of these workspace indexes failed to build. Common reasons include the workspace root not being a recognized project type, file system permission issues, a Sourcegraph server connection timeout during the index push, or running out of the free tier indexing quota.

For self-hosted Sourcegraph (Enterprise or the newer "Sourcegraph App"), the error can also mean the locally running Sourcegraph instance has run out of disk space for its index database, or that the Cody extension's authentication with that instance has expired.

Quick fix (when you need it working in 60 seconds)

Open the VS Code command palette and run Cody: Debug: View Logs. Scroll to the indexing section. The actual error (connection refused, quota exceeded, permission denied) is in here.
Try forcing a re-index: Cody: Reindex Workspace from the command palette.
If you have a multi-root workspace, try opening just one of the workspace folders directly (File > Open Folder) to see if indexing works on a single root. This isolates whether the problem is multi-root specific.
Check your Sourcegraph connection status: Cody: Sign In and verify the instance URL and token are current.
If you're on a free plan, check your indexing quota at sourcegraph.com/users/your-username/settings/cody.

Why this happens

Multi-root workspaces are the most common cause of indexing failure in monorepos. VS Code supports multiple workspace roots via .code-workspace files, but Cody's workspace discovery was designed primarily around single-root projects. In multi-root setups, Cody sometimes picks the wrong root as the "primary" workspace, indexes it, and then fails on the remaining roots because they don't have their own git repositories (they're subdirectories of the monorepo root).

File count limits are another cause. Cody's free tier limits indexing to 10,000 files per workspace. A large monorepo with tens of thousands of files (especially if node_modules isn't gitignored at the right level) can hit this limit. The error message says "indexing failed" without mentioning the file count limit, which makes this hard to diagnose.

Symlinks inside monorepos break Cody's file traversal. Yarn Berry's nodeLinker: node-modules creates a flat node_modules with symlinks throughout. pnpm's default setup also uses symlinks. When Cody's indexer follows a symlink outside the workspace root, it can error out on the unexpected path or loop indefinitely, both of which produce an "indexing failed" state.

For self-hosted Sourcegraph, the Cody backend needs to connect to the Sourcegraph API to push embeddings. If the Sourcegraph instance is running but the Cody endpoint (/.api/cody) is blocked by a proxy or the instance is on an older version that doesn't support the current Cody protocol, the connection fails silently during the index push phase.

Authentication token expiry causes a specific pattern: indexing works for a while, then fails after the token expires. Cody doesn't always surface this as an auth error; it sometimes shows up as a generic indexing failure.

Permanent fix

Create a .cody/ignore file in your monorepo root to exclude directories that don't need indexing:
```
node_modules/
dist/
.next/
coverage/
generated/
.turbo/
```
This dramatically reduces file count and eliminates symlink traversal issues.
For multi-root VS Code workspaces, configure Cody to treat the monorepo root as the single context root rather than each workspace folder:
```
// .vscode/settings.json (in workspace file or at root)
{
  "cody.codebase": "github.com/yourorg/yourrepo"
}
```
Setting cody.codebase explicitly anchors Cody's context to a specific Sourcegraph-indexed codebase rather than trying to index each VS Code workspace root.
Verify your Sourcegraph token hasn't expired:
- Open the Cody sidebar
- Click the account icon
- If you see "Re-authenticate" or the token expiry date is past, refresh it
- For enterprise: use SOURCEGRAPH_TOKEN=$(sg auth print-token) and update the VS Code setting
For self-hosted Sourcegraph, check disk space on the indexer:
```
# SSH to your Sourcegraph instance
df -h /var/lib/sourcegraph/
```
The embeddings database needs at least 2-3x the size of your codebase. Prune old indexed revisions in the Sourcegraph admin panel if needed.
Update Cody to the latest version. The extension releases weekly and multi-root workspace support has improved substantially since 1.20. Open Extensions panel, find Cody, update if available.
If the problem is specifically with Turborepo or Nx monorepos, configure a workspace-level .gitignore that excludes generated cache directories:
```
# .gitignore additions for Cody
.turbo/
.nx/cache/
out/
```
For file count issues on free tier, use Sourcegraph's repository scope feature. Instead of indexing the whole monorepo, scope Cody to the specific packages you're working on:
```
{
  "cody.context.codebase": "github.com/org/repo/packages/auth"
}
```

Prevention

Set up your .cody/ignore file when you first add Cody to a project, not after it breaks. It's a small investment that prevents 80% of the indexing issues that show up later when the project grows.

For teams using enterprise Sourcegraph, run the Sourcegraph admin health check weekly and monitor disk usage on the index storage. Indexing failures at scale usually have warning signs in disk usage trends before they become outright failures.

Keep an eye on the Cody extension changelog at about.sourcegraph.com/blog and the GitHub releases at github.com/sourcegraph/cody. Breaking changes to the indexing format occasionally require a full re-index, and the changelog tells you when to expect that.

For large monorepos where full-codebase indexing is impractical, use Cody's @file and @code context selectors in your chat prompts to manually provide relevant context. It's more manual but it works reliably regardless of indexing status.

When the fix doesn't work

If re-indexing consistently fails after clearing the ignore patterns and verifying authentication, run Cody in debug mode:

export CODY_DEBUG=1

Set this environment variable before launching VS Code. The Cody logs in View > Output > Cody by Sourcegraph will include full indexing trace output, including the specific file or API call that failed.

File issues at github.com/sourcegraph/cody. The Cody team specifically calls out monorepo support as a priority and tracks indexing issues actively. Include your VS Code workspace structure (anonymized), your Cody version, and the debug log section covering the indexing attempt.

For enterprise users with SLAs, use the Sourcegraph support portal rather than GitHub. Enterprise indexing failures often involve server-side configuration that requires access to your Sourcegraph admin panel to diagnose.