Thanks for reporting this. This is a known issue with how the agent maintains worktree context across follow-up messages. When you use /worktree, the agent’s binding to that worktree path isn’t structurally enforced, so on subsequent turns it can lose that context and start making changes in the main repo.
A similar report was confirmed by our team recently, and worktree support is being actively rebuilt to address exactly this class of problem. The goal is to have persistent, deterministic worktree binding rather than relying on the model to remember the path.
For now, the workaround is to explicitly remind the agent in follow-up messages to stay in the worktree. Not ideal, but it helps reduce the drift.