[BUG] Cloud workspace session persists its /sessions mount path into core.worktree of the synced repo's shared config, breaking local worktree creation

Status Open
Reported on v2.1.233
Maintainer reply None cached
Activity 0 comments · opened Aug 16, 2026

Summary

A Claude Code cloud workspace session wrote its own cloud mount path into the synced repository's shared git config:

[core]
	worktree = /sessions/rcw-<redacted>/mnt/main

That config file synced back to my local machine, where /sessions/... does not exist. Two weeks later, every workflow-agent worktree creation (isolation: 'worktree') in that repo failed with:

Failed to create worktree: fatal: Invalid path '/sessions': No such file or directory

The harness then silently retried the agents without isolation, so write-agents committed directly into the shared checkout — the same silent-isolation-loss failure mode as #78486, but with a different root cause: here the bad core.worktree value was written by Claude Code itself (cloud side) and persisted through repo sync.

Environment

  • Local: Claude Code 2.1.233, macOS (Darwin 25.5.0)
  • Cloud session that wrote the value: 2026-08-01 (version unknown)
  • Repo layout: non-bare git directory with linked worktrees inside it (repo.git/ contains HEAD, objects, config, … plus checkouts repo.git/main/, each with a .git file pointing at repo.git/worktrees/<name>). Sessions run from repo.git/main/.

What happens locally

In this layout, git commands whose cwd is the git directory itself resolve core.worktree during setup and die on the dangling path (git reports only the first unresolvable component, hence the bare /sessions):

$ cd repo.git && git worktree list
fatal: Invalid path '/sessions': No such file or directory

Commands run from the linked worktree (repo.git/main/) ignore the shared core.worktree, so everything works there — which is why the poisoned config went unnoticed for two weeks. It only surfaced when the harness's worktree bootstrap resolved the repo root to the git-dir parent and ran git -c core.fsmonitor= worktree add --no-track -B <branch> <path> <sha> from there.

Minimal repro of the local failure

git init --bare probe.git && git -C probe.git config core.bare false
cd probe.git && git commit --allow-empty -m x
git worktree add ./main -b mainbr
git config core.worktree /sessions/rcw-fake/mnt/main   # what the cloud session wrote
git worktree add ./wt -b br
# fatal: Invalid path '/sessions': No such file or directory

Expected

  1. Cloud side: a cloud workspace should not persist a cloud-absolute core.worktree into a repo config that syncs back to the user's machine — scrub it on sync-back, write it somewhere unsynced, or use GIT_WORK_TREE at runtime instead of a config write.
  2. Local side: when worktree creation fails, the fallback to non-isolated execution should be loud (it currently downgrades silently — see also #78486).

Workaround

git config --file repo.git/config --unset core.worktree

After that, both the git-dir-cwd commands and the harness's exact worktree add invocation succeed again.

View original on GitHub ↗