[BUG] Checkpoints nested-repo detection misses submodule/worktree .git files and can false-positive via symlink follow

[0xMink]

Summary

ShadowCheckpointService.getNestedGitRepository() has three correctness issues that cause it to miss nested git repositories (false negatives) or incorrectly detect repositories outside the workspace (false positives).

Impact

• False negatives: Git submodules and worktrees use a .git file (not directory) containing a gitdir: pointer. The current search pattern (**/.git/HEAD) only finds .git directories. Submodule/worktree-style nested repos are completely missed, allowing checkpoints to initialize when they should be disabled.
• False positives: The --follow flag causes ripgrep to traverse symlinks outside the workspace boundary, potentially detecting git repositories that are not actually nested in the workspace.
• Brittle path matching: The current filter uses includes(".git/HEAD") and startsWith(".git/") for path classification, which is imprecise across platforms and path formats.

Reproduction

False negative (submodule case):

1. Create a workspace with a git submodule (the submodule directory will contain a .git file with gitdir: ... content instead of a .git directory)
2. Initialize checkpoints
3. Observe that the nested repo is not detected and checkpoints proceed

False positive (symlink case):

1. Create a workspace containing a symlink that points to a directory outside the workspace
2. The external directory (or its ancestors) contains a .git repository
3. Initialize checkpoints
4. Observe that --follow causes ripgrep to traverse the symlink and detect the external repo as "nested"

Expected behavior

• Nested repos inside the workspace are detected consistently, regardless of whether they use a .git directory or a .git pointer file
• Paths outside the workspace are not considered
• Root-level .git (directory or file) is excluded from detection

Actual behavior

• .git pointer files (submodules/worktrees) are missed entirely
• --follow can cause out-of-workspace matches
• String-based path matching is fragile across separator styles and relative/absolute path variations

Related issues and prior art

• Prompt and entire task contents deleted due to nested git checkpoint; stuck on "Still initializing checkpoint..." #7765 — Task history disappeared when checkpoint init failed with nested submodule
• [ENHANCEMENT] Persistent nested-repo warning with offending path inline #7884 — Enhancement: persistent warning with offending path (PR fix: make nested git repository warning persistent with path info #7885 merged)
• [BUG] Checkpoints feature is disabled because of nested git repos #8433 — Checkpoints disabled with nested repos
• [BUG] Checkpointing disabled when workspace root is not a Git repository #8164 — Workspace root not a git repo triggers misclassification
• Nested git repository detected, cannot use checkpoint feature #10636 — Parent folder with multiple sibling repos triggers nested-repo disable
• PR fix: allow checkpoints with nested git repos by excluding them #8434 — Proposed exclude-based scoping (closed, unmerged)
• PR fix: handle nested git repos gracefully in checkpoints #8863 — fix: handle nested git repos gracefully in checkpoints by daniel-lxs (closed as stale)

[0xMink]

@roomote review please

[roomote]

I've seen your comment and will explore a potential fix. The three issues in getNestedGitRepository() are clear:

1. False negatives: Only searches for **/.git/HEAD via ripgrep, missing submodule/worktree .git pointer files
2. False positives: --follow flag causes symlink traversal outside workspace
3. Brittle path matching: String-based .includes() / .startsWith() filtering is fragile

I'll open a PR to share progress.

[roomote]

Opened PR #11344 with my attempt at addressing this. The fix replaces the ripgrep-based nested repo detection with a recursive fs.readdir walk that handles .git files (submodule/worktree pointers), avoids symlink traversal, and uses proper path operations. Feedback welcome!

[0xMink]

@roomote Thanks for taking a look.

For context: I opened PR #11341 earlier today, which addresses the three problems described in this issue (submodule/worktree .git pointer files, --follow symlink false-positives, and brittle path classification) and adds targeted coverage (37/37 passing).

I reviewed PR #11344. It is a reasonable alternative direction, but I see two risks relative to the issue goals:

1. .git file validation
   PR fix: checkpoint nested-repo detection handles .git files and avoids symlink follow #11344 flags any entry named .git as a nested repo. Git submodules/worktrees use a .git file containing a gitdir: pointer, but a stray .git file without gitdir: would become a false positive that disables checkpoints. PR fix(checkpoints): detect nested repos via .git/HEAD and .git pointer files #11341 validates gitdir: before treating a .git file as a repo marker.

2. Scope and traversal cost
   Replacing the existing ripgrep-based detection with a recursive fs.readdir walk is a broader behavioral change than necessary for this bug, and it increases the risk of slower traversal in large workspaces unless ignore semantics and skip rules are carefully replicated.

If maintainers prefer the filesystem-walk approach, I recommend adding gitdir: content validation for .git files and a regression test for a non-pointer .git file to prevent false positives. Otherwise, I would appreciate review on PR #11341 as the minimal-change fix already aligned to this issue.

[roomote]

@0xMink Thanks for the detailed feedback on PR #11344. Both points are valid:

1. gitdir: validation - Flagging any .git file without checking for gitdir: content is indeed a false-positive risk. I will add content validation so that only .git files containing gitdir: are treated as repo markers.

2. Regression test - I will add a test for a stray .git file without gitdir: to confirm it is not flagged.

I will update PR #11344 with these fixes shortly.

[roomote]

Updated PR #11344 to address both points from @0xMink's feedback:

1. gitdir: validation - findNestedGitEntry now validates .git file content before flagging as a nested repo. Only .git files whose content starts with gitdir: are treated as submodule/worktree pointers. .git directories are still always treated as nested repos.

2. Regression test - Added a test for a stray .git file without gitdir: content, confirming it does not trigger a false positive.

All 34 tests passing, lint and type-check clean. Feedback welcome!