[BUG] Desktop app crashes when git repo discovery resolves to a stray ancestor .git above the project folder (Windows)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet (checked #51236 — real issue, but different root cause: bundled pdf-viewer MCP crashing on cloud-mapped drives, closed as stale; no other open or closed issue matches this ancestor-.git/SCM-scope mechanism)
• [x] This is a single bug report
• [x] I am using the latest version of Claude Desktop

What's Wrong?

Claude Desktop crashes (window closes immediately, no error dialog) when opening a project folder whose git repository discovery walks upward past the folder itself and resolves to an unrelated ancestor directory — in this case an empty, remote-less .git accidentally left at the user-profile root (C:\Users\<user>\.git), several directories above the actual project folder (...\My Drive\_Job Hunt 2026).

git rev-parse --show-toplevel run from inside the project folder confirmed the mechanism directly:

PS C:\Users\Thomas\My Drive\_Job Hunt 2026> git rev-parse --show-toplevel
C:/Users/Thomas

Evidence the desktop app scopes its source-control integration to that resolved (wrong) root, rather than to the folder the user actually selected:

• Task Manager showed a git.exe process pegging CPU after the app had already crashed — a child process outliving its parent, consistent with an SCM scan kicked off against a much larger tree than the 245-file project folder.
• The SCM panel, once the app could stay open, showed a diff of +47,757 −0 against an otherwise-empty repo — consistent with the app having enumerated far more than the project folder's own ~245 files at some point in this scoping process.
• The Claude Code CLI, run from the identical folder and cwd, is completely unaffected — starts and completes turns normally. The CLI performs no recursive SCM/file-watch setup, which isolates the fault to desktop-app-only code (workspace setup / SCM integration / file watcher).
• Reproduced independently on two separate Windows PCs, both syncing the same Google Drive folder in Mirror mode (not Streaming — confirmed via file-attribute checks: 0 dehydrated placeholders, 0 reparse points, 0 long paths, 0 problem filenames, 245 files / 70MB total). Folder content itself is small and structurally unremarkable.
• The crash disappeared immediately after removing the stray ancestor .git (Rename-Item C:\Users\<user>\.git .git_disabled) and initializing git scoped to the project folder itself (git init inside the folder, plus GIT_CEILING_DIRECTORIES set to the profile root as a guard).
• Claude Desktop's own log confirms a crash was recognized on relaunch into this exact path — main.log: Starting local session ... in C:\Users\<user>\My Drive\_Job Hunt 2026 immediately followed by LocalSessions.updateSession: ... options={"title":"System crash recovery","titleSource":"auto"}.
• No Crashpad dump was ever written (Crashpad\reports\ and Crashpad\attachments\ exist but are empty) and the Sentry error queue is also empty (sentry\queue\queue-v2.json contains []). The process is not going through either crash-reporting path — it's being terminated abruptly, not throwing a caught/reported exception.
• Windows Event Viewer had no APPCRASH/Application Error entry for Claude.exe for any of the crashes.

Secondary, non-fatal side effect of the only available workaround: since the fix requires git init-ing the project folder with no remote, the app now logs a git fetch failure on a repeating timer:

[error] Git command failed: git fetch --no-write-fetch-head origin +refs/heads/master:refs/remotes/origin/master
{ code: 128, stderr: "fatal: 'origin' does not appear to be a git repository\nfatal: Could not read from remote repository...\n" }

This doesn't crash the app but indicates the SCM integration doesn't handle a remote-less local repo gracefully either.

What Should Happen?

• Opening a project folder should never crash based on the state of an unrelated ancestor directory.
• Git repository discovery for the desktop app's SCM/workspace integration should not treat a directory outside the explicitly opened project folder as the workspace root for recursive file watching — or if it legitimately needs the true repo root for git operations, it should not recursively watch that entire tree.
• At minimum, whatever fails here should fail visibly (a toast, a disabled SCM panel, a logged and reported error) rather than silently terminating the whole app with no Crashpad dump and no Sentry event.
• The watcher should guard against legacy Windows profile junctions (Application Data, Cookies, My Documents, Recent, SendTo, etc., which loop back on themselves) and should never recursively watch the app's own log/state directories, regardless of where the watch root ends up being anchored.
• A repo with no remote configured (git fetch against a nonexistent origin) should not produce a repeating logged error every few minutes.

Error Messages/Logs

Confirmed root-cause command (run from inside the project folder):
PS C:\Users\Thomas\My Drive\_Job Hunt 2026> git rev-parse --show-toplevel
C:/Users/Thomas

main.log (crash-recovery session, timestamps redacted to relative):
[info] Starting local session local_ddc0ab1c-... in C:\Users\<user>\My Drive\_Job Hunt 2026
[info] LocalSessions.updateSession: sessionId=local_ddc0ab1c-..., options={"title":"System crash recovery","titleSource":"auto"}

Recurring post-fix noise (not the crash, but related):
[error] Git command failed: git fetch --no-write-fetch-head origin +refs/heads/master:refs/remotes/origin/master
{ code: 128, spawnErrno: undefined, stderr: "fatal: 'origin' does not appear to be a git repository\nfatal: Could not read from remote repository.\n\nPlease make sure you have the correct access rights\nand the repository exists.\n" }
[info] [gitDiff] Base ref not found: master in C:\Users\<user>\My Drive\_Job Hunt 2026, falling back to HEAD

Crashpad\reports\ and Crashpad\attachments\ present but empty — no native crash dump generated for any of the crashes.
sentry\queue\queue-v2.json: [] — no queued/caught error event either.
No Windows Event Viewer APPCRASH entry for Claude.exe at any crash timestamp.

Steps to Reproduce

1. On Windows, ensure %USERPROFILE% (or any ancestor of a project folder you're about to open) contains a stray .git directory that is NOT the project folder's own repo — e.g. run git init once by accident in C:\Users\<user>\ and never touch it again. (Confirm with git -C "C:\Users\<user>" rev-parse --show-toplevel.)
2. Create or select any ordinary project folder underneath that ancestor that does not have its own .git — e.g. C:\Users\<user>\My Drive\SomeFolder (no local repo at that level).
3. Open Claude Desktop and select that folder as a project.
4. Submit a prompt.
5. The app window closes immediately with no error dialog. No Crashpad dump, no Sentry event, no Event Viewer entry.
6. cd into the same folder and run the Claude Code CLI directly (claude) — it works normally and completes turns without issue.
7. git rev-parse --show-toplevel from inside the folder returns the stray ancestor's path, not the folder itself, confirming which repo the SCM layer would have latched onto.
8. Fix: rename the stray ancestor .git out of the way, git init the actual project folder (or otherwise ensure git rev-parse --show-toplevel returns the project folder itself), relaunch Desktop, reopen the folder — it now opens and stays open.

Reproduced on two separate Windows PCs against the same Google Drive-synced folder (Mirror mode).

Claude Model

Not sure / Multiple models

Is this a regression?

Yes, this worked in a previous version (this same folder opened successfully in Claude Desktop before this started; exact last-known-working Desktop version not recorded — happy to help narrow this down if useful)

Last Working Version

Unknown — folder previously opened fine in Claude Desktop, but no version number was recorded at that time.

Claude Code Version

2.1.235 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal (PowerShell 7)

Additional Information

• Claude Desktop version: 1.32885.1 (a757f5), built 2026-08-18T19:00:11.000Z
• OS build: Windows 10 Pro 10.0.19045
• Project folder: Google Drive for Desktop, mounted as a folder inside the user profile (not a drive letter), Mirror mode (not Streaming) — confirmed via file-attribute scan (0 dehydrated placeholders).
• The folder itself has no anomalies: 245 files, ~70MB, 0 reparse points, 0 paths over 240 chars, 0 problem filenames.
• A screenshot of the SCM panel showing the +47,757 −0 diff (taken mid-investigation, before the fix) is available but omitted here since it would expose unrelated personal file names; happy to provide a redacted crop if useful.
• Full diagnostic transcript (chat-log form, more verbose than this summary) available on request.