[BUG] bgIsolation worktree tries shared checkout edit before entering worktree
Preflight Checklist
- [x] I have searched existing issues and this has not been reported with the same behavior yet
- [x] This is a single bug report
- [x] I am using the latest version of Claude Code
What's Wrong?
With worktree isolation explicitly enabled in settings.json:
{
"worktree": {
"baseRef": "head",
"bgIsolation": "worktree"
}
}
a background session still appears to attempt its first file modification in the shared/root checkout. That write/edit attempt is blocked or fails, and only after that failure does Claude Code create/enter a worktree and perform the change there.
So the final result is correct, but the execution path is unnecessarily:
- Try to edit the shared/root checkout.
- Get blocked/fail because background worktree isolation is required.
- Create/enter a worktree.
- Repeat the edit successfully inside the worktree.
This burns context and wall-clock time, and it makes the agent reason about a failure that should not happen when bgIsolation is already set to worktree.
What Should Happen?
When worktree.bgIsolation is worktree, background sessions should create/enter the worktree before the first write/edit attempt.
The first file-modifying tool call should target the isolated worktree. There should be no preliminary failed attempt in the project root/shared checkout.
Error Messages/Logs
Exact raw log text was not captured. The visible behavior is a failed/blocked first edit attempt against the root/shared checkout, followed immediately by worktree creation and a successful retry.
Steps to Reproduce
- Use Claude Code v2.1.165.
- Set the following in
settings.json:
``json``
{
"worktree": {
"baseRef": "head",
"bgIsolation": "worktree"
}
}
- Start a background session that needs to modify a file.
- Observe the first file modification attempt.
- Actual: the first edit/write targets the repo root/shared checkout and fails or is blocked. The session then creates/enters a worktree and succeeds on retry.
- Expected: the session creates/enters the worktree first, then performs the initial edit there.
Claude Model
Not sure / Multiple models
Is this a regression?
I do not know.
Last Working Version
Unknown.
Claude Code Version
2.1.165 (Claude Code)
Platform
Other / normal Claude Code usage. Exact API platform was not specified.
Operating System
Ubuntu/Debian Linux
Terminal/Shell
bash
Additional Information
This looks related to the same background/worktree isolation area as these open reports, but it is not the same failure mode:
- #64640: remote-control sessions inherit worktree isolation defaults / baseRef behavior.
- #64452: a subagent already inside a worktree is blocked from Write/Edit.
- #48811:
isolation: "worktree"is ignored for concurrent background agents.
This report is specifically about ordering: even with explicit "bgIsolation": "worktree" and "baseRef": "head", the session seems to spend one failed modification attempt in the shared checkout before entering the worktree. The eventual edit is correct, but the unnecessary failed attempt wastes tokens, context, and time.
Showing cached comments. Read the full discussion on GitHub ↗
4 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
Thanks for the duplicate check. I think this is related to the same background/worktree area, but the failure mode is distinct:
isolation: "worktree"is blocked from editing inside its own worktree.This report is about a real background session with worktree isolation explicitly configured:
The observed problem is ordering: the session first attempts to modify the shared/root checkout, that attempt fails or is blocked, and only then does it create/enter the worktree and retry successfully. The final result is correct, but the extra failed tool attempt wastes context/time and should be avoidable when
bgIsolationis alreadyworktree.So the expected behavior is not "disable the guard" or "avoid worktrees"; it is "enter the configured worktree before the first write/edit attempt."
One important clarification about the entry point:
This is observed in a session opened via Claude Agents / the agents view, not a normal foreground CLI session.
So the scenario is:
settings.jsonhas:``
json
``{
"worktree": {
"baseRef": "head",
"bgIsolation": "worktree"
}
}
The final result still lands in the worktree, but the first failed attempt happens specifically for sessions opened through Claude Agents, and that extra step wastes context and time.
Fixed in 2.1.169 — changelog: "Background sessions are now told that shared-checkout edits are blocked until they enter a worktree, avoiding a wasted rejected edit before
EnterWorktree" (https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md). Closing — reply to reopen if it still happens on the latest version.🤖 Generated with Claude Code