Lazygit 0.66.3 fixes submodule corruption in linked Git worktrees
Two submodule-related bug fixes address worktree corruption and path traversal risks in the terminal Git client.
Summary
Lazygit, the popular terminal user interface for Git, has released version 0.66.3 with two targeted fixes for submodule handling. The first resolves a bug where removing a submodule in a linked worktree would corrupt that same submodule in the main worktree, a failure mode that could silently damage repository state for developers using Git's worktree feature to manage multiple branches simultaneously. The second fix adds validation to ignore submodules whose name or path in .gitmodules points outside the repository, closing a potential path traversal vector.
Both fixes were contributed by Stefan Haller, a regular contributor to the project. The release follows v0.66.2 and contains no new features, focusing entirely on these two edge-case corrections. Lazygit is widely used by developers who prefer keyboard-driven Git workflows in terminal environments.
Submodule and worktree fixes in 0.66.3
- Linked worktree submodule removal: Removing a submodule in a linked worktree no longer breaks the corresponding submodule in the main worktree, fixing state corruption that affected Git's
worktreefeature users. - Path traversal hardening: Submodules with names or paths in
.gitmodulesthat resolve outside the repository boundary are now ignored, preventing potential directory escape. - Scope of changes: Both fixes are confined to submodule handling logic with no API, CLI, or storage format changes; the release is strictly a maintenance update from v0.66.2.
Why it matters
For developers and system administrators who rely on Git worktrees to parallelize branch work without multiple clones, the worktree fix eliminates a subtle data-loss scenario that could waste significant debugging time. The path traversal guard also improves Lazygit's security posture when operating on untrusted or third-party repositories with malformed .gitmodules entries, aligning with broader supply-chain security concerns in open-source development tooling.
Original reference: github.com →