给子 Agent 开启 Worktree 隔离，临时目录创建成功，里面也有项目文件。接下来让它读取当前位置，返回的却还是主工作目录。新副本没有建错，执行工具也没有报错，问题出在两者之间少了一次绑定。
这一步很容易被开关名掩盖。配置里写了 isolation="worktree"，看上去已经把子任务送进另一间工作室；可它拿到的工具箱，可能仍然连着父任务原来的工作台。
在本地 cc-python 实现里，创建 Worktree 与组装子工具是两段代码。沿新路径的去向往下查，能看到一个具体缺口：目录被创建出来，子工具注册表却继续登记父工具对象，新路径没有用于重建这些工具。
因此，要说明子任务在哪里操作，除了证明新目录存在，还需要拿到工具执行位置的证据。一个只读的当前位置检查，往往比隔离开关的名字更有说服力。
新路径为什么没有进入工具？
原 Worktree helper 会在系统临时目录生成路径，再调用 git worktree add --detach。Git 命令成功后，它把新路径返回给调用方。到这里，得到的是一份真实存在的独立工作副本。
AgentTool 收到这个路径后，把它保存到局部变量 worktree_path。随后新建子工具注册表，遍历父注册表，将父工具逐个登记进去。排除少数工具之外，这里没有按新目录重新构造工具实例。
容器虽然换了，里面的工具仍可能是原来那一把。对 Bash 来说，这个区别很直接：构造函数接收 cwd 并存到实例里，执行命令时，再把这个值传给子进程的工作目录参数。
如果父 Bash 构造时绑定主目录，子注册表拿到同一个 Bash 对象，它仍然携带主目录。另一个函数刚刚创建新副本，不会自动修改这个已经保存的字段。
继续看子循环的输入，新路径也没有被作为工作目录传入。子任务系统提示词取预设内容，初始任务来自委派的文本。这条装配链没有把刚创建的路径附到执行工具或任务入口上。
这让“创建成功”与“在新副本执行”之间出现了断点。前者可以从 Git 返回值与目录内容确认，后者要看工具保存了哪个根、传给子进程什么路径，以及实际访问了哪个文件。
排查这类问题时，值得沿同一个路径变量追到底。谁生产它，谁接收它，哪一个操作真正消费它？如果新路径只留在创建与后续清理环节，执行部分就不会因为它存在而自动改向。
