What Changed — A Unified Resolver for Project Context
On April 14, the team behind Claude Code's underlying infrastructure consolidated three different, buggy implementations for a single task: figuring out "what repo is this?" into one shared package: @qmd-team-intent-kb/repo-resolver. This package is now integrated into claude-runtime, meaning it directly affects how Claude Code identifies and scopes its work within your project.
Previously, the edge-daemon, MCP server, and ingestion pipeline each had their own variant of resolveGitContext(). This led to inconsistent behavior, especially around SSH vs. HTTPS remote URLs and monorepo root detection. The new resolver provides one function, resolveRepoContext(), with a single return shape.
What It Means For You — Consistent Project Scoping
For developers using Claude Code daily, this change means more reliable "memory" and context. When Claude Code captures context about your project or scopes a retrieval query, it will now correctly identify the project root, even in complex setups.
The resolver specifically fixes three major pain points:
- Remote URL Normalization:
git@github.com:org/repo.git,https://github.com/org/repo, andssh://git@github.com/org/repo.gitare now all recognized as the same repository. This prevents your work from being scattered across different partitions in Claude Code's memory system based on your clone protocol. - Monorepo Detection: It now correctly detects pnpm, npm workspaces, Nx, Turborepo, and Lerna monorepos. If you're working in
packages/foo/, Claude Code can now understand the workspace root, not just the subdirectory. - Fallback Handling: It gracefully handles repos with no remote set (using a hash of the initial commit) and repos where the primary remote isn't named
origin(like forks with anupstreamremote).
The Key Technical Win: Typed Errors and Transparent Rollout
The design decision that allowed this to ship without breaking existing functionality was the use of typed error classes with a transparent fallback to the legacy resolver. The runtime integration (claude-runtime's DefaultContextProvider) could swap in the new resolveRepoContext() without a "flag day" because the new resolver throws specific, catchable errors. If the new logic fails in an unexpected way, the system can fall back to the old behavior, ensuring stability.
Try It Now — No Action Required, But Understand the Impact
This is a backend change in claude-runtime. As a user, you don't need to run any new commands. However, you should notice improved consistency. If you work in a monorepo or have had issues with Claude Code not recognizing your project context correctly, those problems should now be resolved.
You can verify Claude Code is correctly identifying your repo by observing its behavior when answering questions about project-wide patterns or when using memory features. It should now correctly anchor its context to your project's true root.
The core logic for monorepo detection is straightforward and prioritizes specificity:
// Example of the detection order (from the source)
if (hasPnpmWorkspaceFile(root)) return 'pnpm';
if (hasNpmWorkspacesField(root)) return 'npm';
if (hasNxJson(root) && hasWorkspacesConfig(root)) return 'nx';
if (hasTurboJson(root)) return 'turbo';
if (hasLernaJson(root)) return 'lerna';
return null;
This follows a key principle: the cost of a wrong classification (e.g., calling an Nx single-app project a monorepo) is higher than the cost of an honest unknown (null).
