Description
When using repository worktrees created and managed by the GitHub Copilot App, the Git index is being cleared across multiple worktrees. This initially looks like dotfile directories have been deleted, but the files remain present on disk.
Git reports every tracked file as staged for deletion and the same files as untracked. In one affected worktree:
?? 1380
D 1382
staged deletions: 1382
dot paths staged for deletion: 28
non-dot paths staged for deletion: 1354
existing regular files on disk: 1381
tracked files at HEAD: 1382
This is equivalent to the index state produced by a command such as git rm -r --cached ., although the user did not intentionally run that command. The behavior is occurring in all worktrees used through the GitHub Copilot App, rather than only one repository session.
Steps to reproduce
- Open a repository in the GitHub Copilot App.
- Create or use an app-managed Git worktree session.
- Work in or revisit the session.
- Run
git status --short --untracked-files=all.
- Observe all tracked files staged as deleted and their on-disk copies shown as untracked.
The exact trigger within the session lifecycle is not yet known.
Expected behavior
The app must preserve each worktree's Git index. Opening, using, or revisiting a worktree session should not alter the staged state of unrelated files.
Actual behavior
The complete tracked tree is staged for deletion while the working-tree files remain on disk as untracked files. Hidden paths make the problem especially visible, but both dotfiles and ordinary files are affected.
Environment
- GitHub Copilot CLI: 1.0.80
- Host OS: macOS (Darwin)
- Workspace type: Git worktree
- Repository session managed by the GitHub Copilot App
Workaround
Running git reset rebuilds the index from HEAD without deleting the on-disk files. This can discard legitimate staging state, so it is not a safe general solution when a user already had intentional staged changes.
Description
When using repository worktrees created and managed by the GitHub Copilot App, the Git index is being cleared across multiple worktrees. This initially looks like dotfile directories have been deleted, but the files remain present on disk.
Git reports every tracked file as staged for deletion and the same files as untracked. In one affected worktree:
This is equivalent to the index state produced by a command such as
git rm -r --cached ., although the user did not intentionally run that command. The behavior is occurring in all worktrees used through the GitHub Copilot App, rather than only one repository session.Steps to reproduce
git status --short --untracked-files=all.The exact trigger within the session lifecycle is not yet known.
Expected behavior
The app must preserve each worktree's Git index. Opening, using, or revisiting a worktree session should not alter the staged state of unrelated files.
Actual behavior
The complete tracked tree is staged for deletion while the working-tree files remain on disk as untracked files. Hidden paths make the problem especially visible, but both dotfiles and ordinary files are affected.
Environment
Workaround
Running
git resetrebuilds the index fromHEADwithout deleting the on-disk files. This can discard legitimate staging state, so it is not a safe general solution when a user already had intentional staged changes.