Issue Station
Sign In
Tools hereToolbox

claude-code - 💡(How to fix) Fix Worktree UX: session keying, multi-repo isolation, and gitignored files [1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#52113•Fetched 2026-04-23 07:36:18
View on GitHub
Comments
0
Participants
1
Timeline
3
Reactions
0
Author
JefStatJefStat
Participants
JefStatJefStat
Timeline (top)
labeled ×3

/worktree is great when a task fits cleanly inside a single git repo, but several rough edges make it painful in common real-world workflows. Filing as a bundle since they share a theme.

Root Cause

Worktrees are the main mechanism for parallel agent work and safe experimentation. The current shape biases users toward single-repo, git-repo-only, dev-server-free tasks — a narrow slice of what people actually do.

RAW_BUFFERClick to expand / collapse

Summary

/worktree is great when a task fits cleanly inside a single git repo, but several rough edges make it painful in common real-world workflows. Filing as a bundle since they share a theme.

The pain points

  1. Sessions are keyed by cwd, so worktrees fragment session history. Starting a session in the repo root and then spawning a worktree means claude --resume from either location sees only half the history. There's no obvious way to follow a session across the cwd change.

  2. No way to change a running session's cwd. Once you realize mid-session you wanted to be in a worktree, you can't move the session into it. You either abandon context or abandon the worktree.

  3. /worktree requires a git repo. Useful when you're working in ~/scratch/, a docs-only dir, or any non-repo workspace and want the same isolation guarantee. Today you have to git init just to get a worktree.

  4. Worktrees don't extend to sibling repos touched during the task. My tasks routinely edit repo A while consulting/modifying repo B next to it. The worktree isolates A but the agent still reads/writes the real checkout of B, which defeats the "safe sandbox" promise of worktrees.

  5. Gitignored local config (.env, decrypted secrets, local symlinks) isn't copied into the worktree. First run of pnpm dev / tests inside the worktree fails because every gitignored dev-time file is missing. An opt-in copy list (or a documented convention) would unblock this.

Why this matters

Worktrees are the main mechanism for parallel agent work and safe experimentation. The current shape biases users toward single-repo, git-repo-only, dev-server-free tasks — a narrow slice of what people actually do.

Suggestions (not prescriptive)

  • Session metadata could be keyed by session ID with cwd tracked as a mutable property.
  • Allow /worktree in non-repo dirs via a plain directory copy (opt-in).
  • Let /worktree accept additional repo paths to also worktree.
  • A settings key for "files to copy into each worktree" (.env*, *.local, etc.) with sensible defaults.

Environment

  • Claude Code on macOS (darwin 24.6.0)
  • Worktrees created via /worktree into .claude/worktrees/<name>

extent analysis

TL;DR

To improve the usability of /worktree, consider modifying session metadata to be keyed by session ID and allow mutable cwd, enabling worktree creation in non-repo directories, and implementing a mechanism to copy necessary files into worktrees.

Guidance

  • Session Management: Modify session metadata to use a session ID as the key, with cwd as a mutable property, to allow seamless session continuation across different directories.
  • Non-repo Directory Support: Introduce an option to create worktrees in non-repo directories via a plain directory copy, enabling isolation in various workspace scenarios.
  • Multi-repo Support: Enhance /worktree to accept additional repository paths, ensuring that worktrees can be created for sibling repositories touched during a task.
  • File Copy Mechanism: Implement a settings key for specifying files to copy into each worktree, such as .env files or local symlinks, with sensible defaults to facilitate development and testing within worktrees.

Example

# Example of a potential settings configuration for file copying
claude:
  worktree:
    copy_files:
      - .env
      - .local

Notes

The proposed solutions aim to address the pain points identified in the issue, focusing on enhancing session management, supporting non-repo directories, and improving file handling within worktrees. However, the exact implementation details may vary based on the specific requirements and constraints of the Claude Code system.

Recommendation

Apply workaround: Implementing the suggested modifications to session management, non-repo directory support, and file copying mechanisms can significantly improve the usability and flexibility of /worktree for real-world workflows.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#chain error#conversation history#tool integration#LLM response#prompt template

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING