{"schema_version":"1.0","service":"Publicasta","type":"article","id":881,"slug":"github_desktop_3_6_7_worktree_edge_cases","title":"GitHub Desktop 3.6.7 fixes the edge cases that make worktrees risky","excerpt":"GitHub Desktop 3.6.7 is a focused maintenance release for parallel checkouts: it keeps the current worktree visible, handles dash-prefixed refs safely, repairs a Cygwin path issue, and prevents a Git LFS progress-tracking crash.","language":"en","default_language":"en","canonical_url":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases?lang=en","image":{"url":"https://publicasta.com/storage/projects/10/pages/881/2026/10/b7302cd1-7397-4d9d-94fc-ebfd6382ba07.webp","alt":"Editorial photograph of a laptop and organized project folders representing multiple linked Git worktrees."},"publisher":{"id":10,"slug":"open_source_radar","name":"Open Source Radar","url":"https://publicasta.com/open_source_radar"},"author":{"name":"Anton R"},"published_at":"2026-10-14T13:38:38+00:00","updated_at":"2026-10-14T13:38:38+00:00","content_markdown":"GitHub Desktop 3.6.7 fixes the edge cases that make worktrees risky\n\n ![Editorial photograph of a laptop and organized project folders representing multiple linked Git worktrees.](https://publicasta.com/storage/projects/10/pages/881/2026/10/b7302cd1-7397-4d9d-94fc-ebfd6382ba07.webp)\n\n GitHub Desktop 3.6.7 is a small release with a surprisingly practical target: the moments when a graphical Git client has to represent more than one checkout of the same repository. The release adds a setting that keeps the current worktree visible, fixes handling for names beginning with a dash, repairs an Open in Cygwin path problem, and addresses a crash in Git LFS progress tracking.\n\n None of that changes the basic shape of GitHub Desktop. It remains a desktop client around Git, not a replacement for Git’s repository model. The value is narrower and more useful: if your day now includes parallel branches, linked worktrees, large files, or repositories with unfriendly names, 3.6.7 removes several ways for the interface to get in the way.\n\n That makes this a release worth testing for maintainers and developers who use worktrees regularly. It is not a reason to change a stable team workflow without checking the upgrade on each operating system, and it does not turn GitHub Desktop into a complete worktree management environment. The project’s own changelog and release tag describe a focused maintenance release, while Git’s documentation explains why some of the remaining caveats are structural rather than cosmetic.\n\n ## What changed in 3.6.7\n\n The official [3.6.7 release tag](https://github.com/desktop/desktop/releases/tag/release-3.6.7) lists four groups of changes.\n\n First, branch, remote, and tag names that start with a dash are now handled correctly across fetch, push, checkout, merge, rebase, and worktree operations. A name such as -maintenance is unusual, but Git repositories do encounter names that are awkward at a command-line boundary. A graphical application still has to pass those names safely to Git and distinguish an argument from an option. The fix matters less because most teams use leading-hyphen names and more because it closes a class of input ambiguity in several workflows at once.\n\n Second, the release fixes the Open in Cygwin integration when the repository folder contains spaces or punctuation. This is the sort of bug that can be invisible on a carefully named test directory and immediately painful in a real Windows home directory. The repository may be valid, the shell may be installed, and the integration can still fail if the path is assembled or quoted incorrectly. The release note is concise, but the scope is clear: paths are data, and desktop integrations need to preserve them exactly.\n\n Third, Git LFS progress tracking no longer crashes when it encounters a file read error. That does not make the underlying file readable, and it does not remove the need to investigate storage, permissions, or a damaged checkout. It does mean a progress-reporting failure should no longer take the client down with it. For repositories that store binaries, design assets, datasets, or other large objects through Git LFS, this is the most directly reliability-oriented fix in the release.\n\n Finally, the new Appearance setting keeps the current worktree toolbar segment visible through the Always show worktree list option. The earlier beta changelog describes the intended behavior: the current worktree control remains present instead of disappearing when the rest of the list is collapsed. The difference sounds minor until a repository has several linked checkouts and the user needs to confirm which one is active before committing.\n\n The release also includes the small polish expected in a desktop maintenance update: better contrast for success and failure icons in the checks summary and validation of macOS application bundle paths in the clone dialog. These are not headline features, but they fit the pattern of the release. 3.6.7 is about making boundary conditions more legible and less fragile.\n\n ## Why the worktree setting matters\n\n Git worktrees are not extra clones in the ordinary sense. The [Git worktree documentation](https://git-scm.com/docs/git-worktree) describes a main working tree and zero or more linked worktrees that share most repository data while keeping state such as HEAD and the index separate. In practical terms, one repository can have one checkout on a feature branch, another on a release branch, and a third on a temporary investigation branch without downloading the entire object database three times.\n\n That model is particularly useful for work that changes context often. A maintainer can keep a release branch clean while reviewing a pull request in another directory. A developer can leave a long-running test or local server in one worktree and switch to a bug fix in another. Automated coding tools also make worktrees more visible because they often create isolated checkouts for parallel tasks. The filesystem layout is different, but the human problem is the same: several directories look like the same project, and a mistake can land in the wrong one.\n\n A client that hides the current worktree until a menu is opened adds a small amount of uncertainty to every action. That uncertainty is not dramatic when the repository has one checkout. It becomes expensive when the names are similar, when branches are short-lived, or when a tool creates directories with generic names such as work, app, or checkout.\n\n The new persistent display does not solve identification by itself. GitHub Desktop still needs to expose enough path or branch context for people to tell worktrees apart, and the current issue tracker shows that this remains an active usability concern. An open issue proposes showing a worktree’s full path on hover when several trees share the same folder basename. That is a useful reminder: keeping the list visible is an improvement in discoverability, not a complete naming scheme.\n\n The right way to read the change is therefore modest. It makes the current context harder to forget. It does not guarantee that the selected directory is the one you intended, and it does not replace checking the branch and path before an irreversible action.\n\n ## The release sits on top of Git’s own constraints\n\n Some worktree surprises cannot be fixed entirely in a client. Git deliberately shares refs and objects across worktrees while maintaining per-worktree state. The documentation notes that HEAD and the index are separate, but many refs remain shared. A branch is normally checked out in only one worktree at a time, and Git will refuse some operations unless the user explicitly forces them.\n\n That distinction explains why a worktree can be cheap and still require discipline. Creating a second checkout does not create an entirely independent repository. A fetch can update shared remote-tracking refs. Configuration may be shared unless worktree-specific configuration is enabled. Hooks, generated files, build caches, and environment files may behave as though all checkouts belong to one larger project even when the source directories are separate.\n\n The cleanup rules matter too. Git records administrative information for linked trees inside the repository’s worktrees directory. If somebody deletes a worktree folder in the file manager, the metadata can remain until it is pruned. The supported path is to use git worktree remove for a clean tree, or git worktree prune after verifying that a missing tree is truly gone. If a directory is moved manually, git worktree repair can reconnect the metadata.\n\n GitHub Desktop can present these states more clearly, but it cannot change them safely. A user who interprets a visible worktree list as a list of independent clones may still make the wrong assumption about shared branches, configuration, or object storage. The release is best used alongside the Git model, not as a substitute for it.\n\n ## The dash-prefixed name fix is about parsing, not style\n\n Leading hyphens are easy to dismiss as a naming convention nobody should use. That view misses the engineering lesson in the fix. Many command-line programs use a dash to introduce options. When a valid branch, remote, tag, or path also begins with a dash, every layer that constructs a command must preserve the distinction between a value and a flag.\n\n A client can address this in several ways: careful argument-array handling, explicit end-of-options markers where supported, validation, or a combination of these techniques. The important outcome for a user is that ordinary operations do not reinterpret a repository name as a command option.\n\n The breadth of the 3.6.7 note is worth paying attention to. The fix is not limited to checkout. It covers fetch, push, merge, rebase, and worktree actions, which suggests that the problematic value can travel through multiple command paths. A repository may appear normal until a remote or tag with the same naming shape is involved. Fixing the family of operations is more valuable than patching one visible menu item.\n\n Maintainers should still treat unusual ref names as a compatibility test. If a project’s automation, release scripts, hosting hooks, or documentation assume that every branch name is a conventional word separated by slashes, the desktop client is only one part of the system. 3.6.7 reduces one client-side risk; it does not make every third-party integration robust.\n\n A small test matrix is enough to validate the behavior without turning it into a production experiment:\n\n - Create a disposable repository and a branch with a leading hyphen.\n- Exercise fetch, checkout, merge, and rebase locally before involving a shared remote.\n- Try a remote or tag with the same shape only if the repository policy permits it.\n- Confirm the command-line and web interfaces used by the team agree on the ref name.\n- Remove the test refs cleanly after the check.\n\n The point is not to recommend leading-hyphen names. It is to check that an existing repository with awkward names remains operable.\n\n ## Git LFS: a crash fix is not a storage diagnosis\n\n Git LFS changes the failure surface of a repository. Git stores pointer files in the normal history while large content is managed through an LFS server and downloaded when needed. A progress indicator therefore sits between the user interface, the local filesystem, Git’s process, and the LFS transfer. A read error can be caused by permissions, a disappearing file, antivirus interference, a network-mounted directory, a full disk, or a problem in the transfer itself.\n\n The 3.6.7 change addresses the client’s response to one of those errors: progress tracking should not crash the application. That is useful because a crash destroys context. The user may lose the visible operation state and have to determine whether the transfer completed, failed, or left a partial file. A surviving client can show the error and let the user inspect the repository.\n\n It would be a mistake to describe this as an LFS data-integrity guarantee. It is a resilience improvement in the reporting path. After upgrading, teams should still verify large-file operations with a test repository or a non-critical checkout, especially on machines that use network shares, external disks, aggressive endpoint security, or unusual filesystem permissions.\n\n If a transfer fails, check the basics before retrying repeatedly. Confirm free disk space and write permissions. Check whether the path is local and stable. Look at the LFS logs and the repository’s configured endpoint. Verify the checkout with the project’s normal build or asset validation process. A graphical application remaining open is helpful, but it is not proof that the object is complete.\n\n This is also where the open-source nature of GitHub Desktop helps with accountability. The [repository](https://github.com/desktop/desktop) is public, its changelog records issue references, and the application metadata identifies the project as MIT-licensed. That license makes the code available for inspection and reuse, subject to the project’s trademark limitations and the licenses of bundled dependencies. It does not create a support contract or guarantee that every integration behaves uniformly on every platform.\n\n ## Open in Cygwin and the unglamorous importance of paths\n\n The Cygwin fix belongs to a wider category of desktop software failures: the application understands a Windows path, the target shell expects a POSIX-like path, and the boundary between them contains spaces or punctuation. A path such as a directory named Open Source or a folder containing parentheses is ordinary to a filesystem and a common source of quoting errors in launchers.\n\n For users, the practical question is whether the repaired integration matches their actual directory layout. If the repository lives under a path with spaces, parentheses, brackets, ampersands, or non-ASCII characters, test the menu action after upgrading. Test it from a repository that is not disposable, but do not use an active release checkout for the first validation. Confirm that Cygwin opens in the intended directory and that the shell sees the same files as the desktop client.\n\n This change also illustrates why GUI release notes can feel smaller than the bugs they fix. The feature itself is just a menu action. The failure can block an entire workflow for people who use a Unix-like toolchain on Windows. A reliable path handoff is infrastructure, even if it is not an exciting feature.\n\n The same caution applies to scripts launched from the client. Avoid assuming that the current working directory is enough context. Scripts should resolve their repository root, handle spaces, and fail with a visible diagnostic when the path does not exist. The application can pass a correct path; the called tool still has to consume it correctly.\n\n ## Who should update first\n\n The strongest case for updating quickly is a developer who uses several linked worktrees inside GitHub Desktop, works with Git LFS, uses Cygwin on Windows, or has repositories with unusual ref names. Those users are closest to the affected paths and can notice whether the fixes match their workflow.\n\n A second group is maintainers who are onboarding contributors with mixed operating systems. A release that removes a path-specific or naming-specific failure can reduce support load, but it is worth publishing the project’s tested versions and setup expectations rather than treating the desktop update as a universal fix.\n\n For a single-checkout user on a stable machine, the urgency is lower. The release does not advertise a large new feature or a security response in the notes cited here. Updating is still reasonable as normal maintenance, but there is little benefit in disrupting a controlled environment without a compatibility check.\n\n The safest rollout is staged:\n\n 1. Install 3.6.7 on one machine that represents the team’s real workflow.\n2. Open a repository with a linked worktree and confirm that the current worktree remains visible.\n3. Exercise the normal branch, commit, fetch, push, and pull-request flow.\n4. If relevant, test an LFS transfer and the Open in Cygwin action from a path with spaces.\n5. Check macOS, Windows, and Linux separately if the team supports more than one platform.\n6. Only then update the documented baseline for contributors.\n\n The release is small enough that this process should be quick. It is also specific enough that a generic smoke test can miss the exact bugs it fixes.\n\n ## What GitHub Desktop still is not\n\n GitHub Desktop is not a full replacement for Git’s command line. It does not hide the distinction between a worktree and a clone, and it cannot decide whether a branch should be shared, removed, locked, or pruned. Advanced repository maintenance still belongs to Git commands and the project’s own operational documentation.\n\n It is not a complete terminal replacement for Cygwin either. The repaired integration opens another environment; it does not unify Windows and POSIX path semantics throughout every tool. A team that mixes PowerShell, Git Bash, Cygwin, WSL, containers, and native build tools should keep path assumptions explicit.\n\n It is also not a security boundary for repository content. Opening a repository can invoke hooks, render untrusted data, call external tools, or interact with credentials depending on the workflow. The changelog improvements are valuable, but ordinary precautions remain appropriate: review repository scripts, limit credentials, keep dependencies updated, and separate experimental checkouts from sensitive environments.\n\n Finally, open source does not mean every part of the distribution has the same license. The repository identifies the application as MIT-licensed, while dependencies and GitHub trademarks have their own terms. Organizations that redistribute a modified build should review the repository’s license files, third-party notices, and branding rules rather than relying on the word open source as a blanket legal conclusion.\n\n ## Alternatives for worktree-heavy teams\n\n The first alternative is the Git command line itself. It exposes the complete worktree model and is the reference point for operations such as add, list, lock, move, repair, prune, and remove. A team that depends heavily on worktrees should know these commands even if most daily work happens in a GUI.\n\n The second is an editor or IDE with explicit multi-root and worktree support. The advantage is proximity to code, terminals, tests, and language tooling. The trade-off is that the interface may make it easier to open several folders while giving less visibility into shared Git state. Teams should agree on naming conventions and workspace labels.\n\n The third is a dedicated worktree manager or a small set of shell scripts. These can impose a directory layout, create predictable names, and remove stale trees. They also create a new maintenance surface. A script that is convenient on one machine can become dangerous when it assumes a path layout, deletes a dirty tree, or ignores locks and untracked files.\n\n GitHub Desktop 3.6.7 fits best when a team wants a visual client for everyday GitHub operations but still accepts Git’s worktree rules. It is a useful middle layer, not an abstraction that erases repository state.\n\n ## The practical verdict\n\n GitHub Desktop 3.6.7 is worth testing if worktrees, Git LFS, Cygwin, or awkward ref names are part of your working life. The visible worktree setting improves context, the dash-prefixed-name fix closes a real argument-handling class of bugs, the Cygwin repair makes a common Windows path boundary less brittle, and the LFS change keeps a file-read failure from taking the client down.\n\n For everyone else, this is a normal maintenance update with a low-drama profile. The release is more interesting as a signal about where desktop Git clients are being pressured: parallel checkouts are becoming ordinary, repositories contain more generated and binary content, and developers move constantly between graphical and terminal environments.\n\n Install it, then test the edges that matter to your repository. Look at the active worktree before committing. Keep branch and path names visible. Use Git’s own worktree commands when removing or repairing directories. Treat an LFS crash fix as improved resilience, not as a verification step. That is enough to get the value from 3.6.7 without asking a small release to promise more than it does.","available_translations":[{"language":"ar","title":"GitHub Desktop 3.6.7 يصلح الحالات الطرفية التي تجعل Worktrees محفوفة بالمخاطر","html_url":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases?lang=ar","markdown_url":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases.md?lang=ar","json_url":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases.json?lang=ar","api_url":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/github_desktop_3_6_7_worktree_edge_cases?lang=ar"},{"language":"de","title":"GitHub Desktop 3.6.7 behebt die Sonderfälle, die Worktrees riskant machen","html_url":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases?lang=de","markdown_url":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases.md?lang=de","json_url":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases.json?lang=de","api_url":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/github_desktop_3_6_7_worktree_edge_cases?lang=de"},{"language":"en","title":"GitHub Desktop 3.6.7 fixes the edge cases that make worktrees risky","html_url":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases?lang=en","markdown_url":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases.md?lang=en","json_url":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases.json?lang=en","api_url":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/github_desktop_3_6_7_worktree_edge_cases?lang=en"},{"language":"es","title":"GitHub Desktop 3.6.7 corrige los casos límite que vuelven arriesgados los worktrees","html_url":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases?lang=es","markdown_url":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases.md?lang=es","json_url":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases.json?lang=es","api_url":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/github_desktop_3_6_7_worktree_edge_cases?lang=es"},{"language":"fr","title":"GitHub Desktop 3.6.7 corrige les cas limites qui rendent les worktrees risqués","html_url":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases?lang=fr","markdown_url":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases.md?lang=fr","json_url":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases.json?lang=fr","api_url":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/github_desktop_3_6_7_worktree_edge_cases?lang=fr"},{"language":"pl","title":"GitHub Desktop 3.6.7 naprawia sytuacje brzegowe, które utrudniają pracę z worktree","html_url":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases?lang=pl","markdown_url":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases.md?lang=pl","json_url":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases.json?lang=pl","api_url":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/github_desktop_3_6_7_worktree_edge_cases?lang=pl"},{"language":"ru","title":"GitHub Desktop 3.6.7 устраняет пограничные случаи, из-за которых worktree становятся рискованными","html_url":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases?lang=ru","markdown_url":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases.md?lang=ru","json_url":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases.json?lang=ru","api_url":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/github_desktop_3_6_7_worktree_edge_cases?lang=ru"},{"language":"zh","title":"GitHub Desktop 3.6.7 修复了让 worktree 变得棘手的边缘问题","html_url":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases?lang=zh","markdown_url":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases.md?lang=zh","json_url":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases.json?lang=zh","api_url":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/github_desktop_3_6_7_worktree_edge_cases?lang=zh"}],"_links":{"self":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases.json?lang=en","api":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles/github_desktop_3_6_7_worktree_edge_cases?lang=en","html":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases?lang=en","canonical":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases?lang=en","markdown":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases.md?lang=en","json":"https://publicasta.com/open_source_radar/github_desktop_3_6_7_worktree_edge_cases.json?lang=en","channel":"https://publicasta.com/api/public/v1/channels/open_source_radar","channel_articles":"https://publicasta.com/api/public/v1/channels/open_source_radar/articles","search":"https://publicasta.com/api/public/v1/search","documentation":"https://publicasta.com/api-docs#reading-publicasta","openapi":"https://publicasta.com/api-docs/openapi.json","llms":"https://publicasta.com/llms.txt"}}