Issue Station
Sign In
Tools hereToolbox

claude-code - 💡(How to fix) Fix [BUG] remote-control --spawn worktree silently deletes completed session worktrees and commits on session end [1 comments, 2 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#48131•Fetched 2026-04-15 06:32:17
View on GitHub
Comments
1
Participants
2
Timeline
5
Reactions
0
Author
nemasha42nemasha42
Participants
github-actions[bot]github-actions[bot]nemasha42nemasha42
Timeline (top)
labeled ×4commented ×1

Error Message

Error Messages/Logs

RAW_BUFFERClick to expand / collapse

Preflight Checklist

  • I have searched existing issues and this hasn't been reported yet
  • This is a single bug report (please file separate reports for different bugs)
  • I am using the latest version of Claude Code

What's Wrong?

Bug Description

When using claude remote-control --spawn worktree, all worktree branches and commits are silently deleted when sessions end (whether completed or failed). There is no window to review or merge the work. This results in permanent data loss.

Steps to reproduce

  1. claude remote-control --spawn worktree --name "my-project"
  2. Connect from Claude iOS app, start multiple sessions
  3. Give each session a coding task
  4. Wait for sessions to complete (or hit rate limit)
  5. Check git worktree list and git branch — everything is gone

Expected behavior

Completed session worktrees should persist with their branches and commits intact until the user explicitly merges or removes them. At minimum, a warning or merge prompt should appear before cleanup.

Actual behavior

Worktrees and their branches are deleted the moment a session ends. The server terminal shows "Session completed" but the work is already gone. git reflog, git branch, and git worktree list show no trace.

In my case, 5 sessions ran (3 completed after ~4 hours each, 2 failed at rate limit). All work was lost despite the server running continuously.

Environment

  • Claude Code version: 2.1.76
  • OS: macOS (Apple Silicon MacBook Air)
  • Plan: Max
  • Terminal: default macOS Terminal
  • Connected via: Claude iOS app

Impact

Multiple hours of agent work and significant rate limit usage (~20% weekly) permanently lost with no recovery path. The completed sessions had working code that was never merged to any persistent branch.

What Should Happen?

Expected behavior

Completed session worktrees should persist with their branches and commits intact until the user explicitly merges or removes them. At minimum, a warning or merge prompt should appear before cleanup.

Error Messages/Logs

Steps to Reproduce

Steps to reproduce

  1. claude remote-control --spawn worktree --name "my-project"
  2. Connect from Claude iOS app, start multiple sessions
  3. Give each session a coding task
  4. Wait for sessions to complete (or hit rate limit)
  5. Check git worktree list and git branch — everything is gone

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

No response

Claude Code Version

2-1-76

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

No response

extent analysis

TL;DR

The issue can be mitigated by modifying the claude remote-control command to prevent automatic cleanup of worktrees after session completion.

Guidance

  • Review the claude remote-control command options to see if there's a flag or parameter that can be used to prevent automatic worktree cleanup.
  • Check the Claude Code documentation for any configuration settings that control worktree behavior.
  • Consider using git worktree commands directly to manage worktrees and prevent deletion.
  • Verify that the issue is indeed a regression by testing an earlier version of Claude Code, if possible.

Example

No code snippet is provided as the issue is related to command-line tool behavior, but an example of using git worktree to manually manage worktrees could be:

git worktree add <path> <branch>

This command creates a new worktree at the specified path and branch, which can be used to persist worktree data.

Notes

The issue seems to be specific to the claude remote-control command and its interaction with worktrees. Without more information about the command's internal behavior, it's difficult to provide a definitive solution. The guidance provided is based on the assumption that the issue is related to the command's configuration or usage.

Recommendation

Apply a workaround by using git worktree commands directly to manage worktrees, as the root cause of the issue is unclear and may require further investigation. This approach allows for more control over worktree creation and deletion, potentially preventing data loss.

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…

FAQ

Expected behavior

Completed session worktrees should persist with their branches and commits intact until the user explicitly merges or removes them. At minimum, a warning or merge prompt should appear before cleanup.

#api#latency issue#model loading#dependency error#configuration error

Still need to ship something?

×6

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

Back to top recommendations

TRENDING

claude-code - 💡(How to fix) Fix [BUG] remote-control --spawn worktree silently deletes completed session worktrees and commits on session end [1 comments, 2 participants]