[BUG] @mention path autocomplete does not traverse into nested git repositories

Status Closed — not planned
Reported on v2.1.94
Maintainer reply None cached
Activity 6 comments · opened Apr 8, 2026 · closed Jun 20, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

When running Claude Code from a parent directory that contains nested git repositories (directories with their own .git), the @ mention path autocomplete does not index or traverse into those nested repos — even when using respectGitignore: false in settings and --add-dir to explicitly add those directories as workspaces.

What Should Happen?

Files inside nested git repositories (added via --add-dir or made visible via respectGitignore: false) should be indexed and available for @ mention path autocomplete when navigating their paths (e.g., @subproject.Api/src/Program.cs).

Error Messages/Logs

Steps to Reproduce

  1. Run claude (or claude --add-dir ./subproject.Api --add-dir ./subproject.Web) from subscription/
  2. In the chat, type @subproject.Api → the directory appears in autocomplete ✅
  3. Type @subproject.Api/src/ → no results, autocomplete is blank ❌
  4. Type @Program.cs (fuzzy file search) → no results ❌

Claude Model

None

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

2.1.94

Platform

Anthropic API

Operating System

Other

Terminal/Shell

Other

Additional Information

Original Issue: https://github.com/anthropics/claude-code/issues/32924

View original on GitHub ↗

6 Comments

fabrizioanichini · 6 months ago

Same issue here. I run claude from a parent directory containing multiple nested git repos (each with their own .git). The @ picker shows the top-level directories but can't browse into them. Would be very useful for monorepo-style setups where you work across multiple projects from a shared root.

Soljourner · 6 months ago

Same, I've had this issue for months now, had Claude build a hook that fixes the path lookup and it was working until the latest update with Opus 3.7.. now we're back to not working. All I see in github issues are "this is a duplicate of blah blah blah issue" with zero resolutions or workarounds.

jahseng-lee · 4 months ago

Adding a +1 for this too.

{
  "respectGitignore": false,
  "permissions": {
    "additionalDirectories": [
      "/Users/<user>/projects/<repo I want to run `claude agents` in>/backend/example-backend-repo",
      "/Users/<user>/projects/<repo I want to run `claude agents` in>/frontend/example-frontend-repo",
      "/Users/<user>/projects/<repo I want to run `claude agents` in>/infrastructure/example-instrastructure-repo",
    ],
    "allow": [
      // ...
    ]
  }
}

Doesn't resolve any repos. @<repo name> only works for really recent repos that ran claude inside the directory.

github-actions[bot] · 3 months ago

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

pandysp · 3 months ago

@reduardo7 @Soljourner @jahseng-lee @fabrizioanichini @chrislloyd

I found out that the @repo picker is also populated by any dirs that's had a background session running or completed. It's annoying though because it clutters your view with completed background agent sessions. Once you delete them the @repo picker doesn't list the dirs anymore.

Another ugly workaround is to symlink the nested dirs to the top level. You need to restart claude agents and they appear. But I really don't like the maintenance of these symlinks.

Have you found any other workarounds?

github-actions[bot] · 1 month ago

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.