claude-code - 💡(How to fix) Fix [BUG] Cannot open Claude Code's own worktrees from Desktop project picker — they live in hidden `.claude/worktrees/` which the macOS folder dialog won't show [1 comments, 2 participants]

Summary

Claude Code Desktop puts worktrees it creates at .claude/worktrees/<name>/. That path is hidden from the macOS folder-picker dialog by default because .claude starts with a dot. So when the natural workaround for a broken EnterWorktree (see #60624) is "just open the worktree as a Claude Code project from the project picker," users literally cannot — the picker dialog doesn't expose dotfiles, and even with Cmd+Shift+. toggled some users can't reliably navigate in.

The result: a worktree that Claude Code itself created, in a path Claude Code itself chose, is unreachable from Claude Code's own UI.

Reproduction

1. From any Claude Code surface (CLI works), call EnterWorktree to create a worktree — e.g. my-feature-branch. Claude Code creates it at <repo>/.claude/worktrees/my-feature-branch/.
2. Exit that session.
3. Open Claude Code Desktop.
4. Try to add <repo>/.claude/worktrees/my-feature-branch/ as a project. The folder picker dialog defaults to hidden-files-off, so .claude/ is invisible. Even after Cmd+Shift+. the navigation experience is poor and several Electron/native picker combinations refuse to descend into dot-prefixed parents.

Why this is a real problem (not a user-error)

The two failure modes compound:

• EnterWorktree can't attach to an existing worktree (#60624 — regression of #45024).
• The "just open it as a project" fallback is blocked by the dotfile convention.

Together these mean: if you create a worktree in one Claude Code session and exit before committing, there is no in-product way to get back into it. Your only recourses are: rebuild the worktree (destroys uncommitted work), edit the worktree files via the main-repo cwd by absolute path (defeats the whole point of worktree-aware UI), or quit and relaunch from a terminal that's already cd'd into the worktree (defeats the whole point of Desktop).

Suggested fix (pick one or all)

1. Dedicated worktree picker in Desktop, not a file picker. Claude Code already knows where it put worktrees — for any project it's opened, it can enumerate <repo>/.claude/worktrees/* and present them as a first-class list ("Open existing worktree…"). No file picker needed. This is the right fix.
2. Folder picker should default to showing hidden directories when launched from Claude Code, since Claude Code's own state lives under .claude/ and users shouldn't have to know macOS keybindings to access it.
3. Stop putting worktrees in a hidden directory. Move the default to <repo>/worktrees/ or <repo>/.worktrees/ only as opt-in. Related: #48967 (same root cause — hidden .claude/ breaks other discovery flows).

Option 1 is the cleanest and doesn't require users to learn macOS Finder trivia.

Environment

• Claude Code Desktop 2.1.144
• macOS 26.3.1 (arm64)

Related

• #60624 — EnterWorktree regression: errors instead of attaching when worktree exists. With that fixed, this issue would be far less acute (you wouldn't need the file-picker fallback in most cases). But it'd still bite the "I closed Desktop and want to re-open into the worktree directly" workflow.
• #48967 — EnterWorktree puts worktrees inside .claude/, breaking skill/slash-command discovery. Same root cause (.claude/ is the wrong parent dir for user-visible artifacts), different symptom.
• #45024 — original issue that #60624 regresses.