extraction/index.ts bounds every git call it makes; worktree.ts,
git-hooks.ts, and the installer's npm install -g did not, so a stuck
subprocess blocked the caller indefinitely. Worst case was the daemon:
gitWorktreeRoot/gitCommonDir run (memoized) on the main event loop while
serving MCP clients, where an unbounded git hang would trip the 60s
liveness watchdog and SIGKILL a healthy daemon. git calls get 5s, the
interactive npm install 120s. Regression tests assert the option through
a mocked child_process plus a per-file call-site sweep.
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Indexing a super-repo now descends into its submodules and gitlinked clones, so
a query run from inside one resolves up to the parent's unified index — whose
graph DOES contain that nested repo's files. But the git-worktree-mismatch
warning still fired, telling the agent the results were from "a different working
tree" and to run `codegraph init -i` — which would split the submodule back into
its own index and undo the unified view. A false positive carrying harmful advice.
Distinguish a genuine borrowed worktree (the SAME repository on a different
branch — shares a git common dir with the index root) from a submodule/embedded
clone (a DIFFERENT repository — its own common dir), and suppress the warning
only for the latter. Add gitCommonDir() for the check. The issue-#155 linked-worktree
case is unchanged.
Verified end-to-end: the warning no longer fires for a submodule-rooted MCP
session and still fires for a real linked worktree. Edit-sync (manual sync +
the live watcher) keeps the nested repo's files current on both macOS and Linux
(active-submodule and bare-gitlink shapes), so suppressing the warning is safe.
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
On Windows, v0.9.5's detached shared daemon (#411) has no inherited console,
so any console-subsystem child it spawns gets a fresh visible console window
unless the spawn passes `windowsHide: true`. The fix adds the flag to all
ten `spawnSync` / `execFileSync` / `execSync` call sites across extraction,
sync, installer, and the WASM-flags relaunch. macOS/Linux ignore the option,
so this is a no-op elsewhere.
Fixes#485, #510, #530.
Co-authored work:
- #498 (csw-chen) — full sweep across extraction, sync, installer, and wasm-runtime. **This is the change being merged.**
- #505 (yushengruohui) — independently identified and fixed the 7 git execFileSync sites. Superseded by #498's broader sweep; same diagnosis.
- #521 (JirA44) — independently identified and fixed the WASM-runtime spawnSync re-exec. Superseded by #498's broader sweep; same diagnosis.
Validated on Windows 11 ARM64 (Parallels): a detached parent's 15 git spawns produce 15 visible black flash-windows without the fix and 0 with it.
When a worktree is nested inside the main checkout (e.g. agent tools that place
worktrees under .claude/worktrees/<name>/), the nearest-.codegraph walk resolves
UP to the main checkout's index and queries silently return that tree's code —
usually a different branch. Symbols changed only in the worktree are invisible,
and nothing tells the user (#155).
Two layers:
- **Detection** (src/sync/worktree.ts): detectWorktreeIndexMismatch() compares
the caller's git working-tree root vs the resolved index root via
'git rev-parse --show-toplevel'. Best-effort; no git / not a repo / monorepo
subdir / plain-ancestor index → no warning.
- **Surface**: codegraph status (CLI + MCP) embeds a verbose multi-line warning;
every MCP read tool (search/context/trace/callers/callees/impact/explore/node/
files) prefixes a compact one-line notice naming the borrowed index and the
fix (codegraph init -i in the worktree). Detection is cached per session per
start path, so it costs at most a single pair of 'git rev-parse' spawns per
project no matter how many tool calls — respects the wall-clock-latency
invariant.
Real-git tests (no mocking) cover both layers. Validated on macOS / Linux
(Docker) / Windows (Parallels VM); 11/11 worktree tests green on all three.
Closes#155
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
csw-chenandGitHub
