[BUG] Desktop (SSH): "Worktree location" accepts only a local path, so remote sessions always fall back to the remote $HOME
Summary
Desktop has a single "Worktree location" setting and it resolves against the local
filesystem — on Windows, a local Windows path. There is no way to enter a path on an SSH
remote. So for SSH sessions the setting can never hold a usable value, and every remote
worktree lands in the remote user's home directory at$HOME/<repo-basename>-<16 hex>/<session-name>/, regardless of what the setting says.
A Windows path and a Linux remote path cannot both live in one field. The setting is
structurally unusable for SSH sessions.
Steps to reproduce
- Desktop on Windows. Settings → Claude Code → Worktree location: the field offers a local
Windows path only; there is no way to specify a path on an SSH host.
- Add an SSH connection to a Linux host and open a repository on it as the session folder.
- Start a new session with the worktree option selected.
Expected
Some way to say where worktrees go on that remote host — and, with the setting at its default,
worktrees at <project-root>/.claude/worktrees/ on the remote.
Actual
The worktree is created under the remote $HOME, nowhere near the project:
$HOME/myrepo-a8ae6b289e243a34/
├── .claude-managed-worktrees
├── session-one-bea3e2
├── session-two-0d2256
└── session-three-3bde66
Nothing is written to <project-root>/.claude/worktrees/ on the remote.
The app writes a marker file into that home directory, .claude-managed-worktrees, which
points at the setting as the reason it chose the location — a setting that cannot be given a
remote value:
This directory holds Claude Code session worktrees placed here by the claude-ssh daemon (the "Worktree location" setting). Its subdirectories are managed checkouts; open the repository itself, not one of them, as a session folder. Safe to delete once the directory is otherwise empty.
Not caused by the remote OS
The remote is Fedora Atomic, where /home is a symlink to /var/home, so the symlink
refusals documented for worktree creation are the obvious suspect. They are not the cause:
- The fallback root the app chose,
$HOME/myrepo-<hash>/, is itself under that symlink and
works fine — three worktrees in it, all healthy and registered.
- The repository root is already symlink-free (
/var/home/...), so the default location
resolves to a path with no symlink in it to refuse.
- Both spellings normalize: session records are stored under the
/var/homeform, and the
CLI's own containment check realpaths both sides before comparing, so the two spellings are
never compared as strings.
No workaround
- A remote value in the setting: not expressible. The field is local-filesystem only.
- Per-connection setting: none.
sshConfigsentries acceptid,name,sshHost,
sshPort, sshIdentityFile only.
- Settings file on the remote: no key at any scope.
worktree.*acceptsbaseRefand
bgIsolation only, so the remote host's own ~/.claude/settings.json can't override it.
WorktreeCreatehook, the documented way to relocate worktrees: not called by Desktop —
#29716, open since 2026-03-01.
- Creating worktrees manually with git and opening each as a session folder: doesn't scale
(this repository runs 107 registered worktrees), and for the documented default location the
SSH folder picker can't open hidden directories anyway — #93909.
Asks
Any one of these unblocks it:
- Let the worktree location be set per SSH connection, entered as a remote path.
- Accept a value relative to the project root, so one setting resolves correctly on every host
regardless of platform.
- Failing a setting, have SSH sessions use the documented default
<project-root>/.claude/worktrees/ on the remote rather than the remote $HOME.
Environment
- Desktop app: Claude Code Desktop on Windows
- Remote host: Fedora Linux 44 (Atomic), kernel 7.2.4
ccd-clion remote: 2.1.271- Claude Code CLI on remote: 2.1.274
Related: #27282 (configurable worktree location), #29716 (WorktreeCreate not called in
Desktop), #93909 (SSH folder picker can't open .claude/worktrees)