What happened?
fetch-pr creates the review worktree at a fixed path, .qwen/tmp/review-pr-<n>. During a round-4 high-effort review of PR #9118, the worktree was deleted five minutes after creation — by another session reviewing/finishing the same PR (the cleanup bypass audit recorded 5 unvouched same-account PR writes in the same time window).
The failure surfaces are asymmetric and unhelpful:
comment-status degraded with a warning (all code facts became unknown);repo-context hard-failed with a bare ENOENT: no such file or directory, lstat '…/review-pr-9118' that does not say "the worktree is missing — re-run fetch-pr";- the review had to re-run
fetch-pr from scratch, and remains exposed to the same race for its entire lifetime (any concurrent fetch-pr/cleanup for the same PR number can remove the worktree again mid-run).
What did you expect to happen?
Concurrent reviews of the same PR must not destroy each other's state:
- isolate the worktree per run (e.g. a random/session suffix,
review-pr-<n>-<rand>) or take a lock on the path;
- commands that need the worktree fail with an actionable message when it disappears mid-run ("worktree missing — re-run
fetch-pr"), not a raw ENOENT.
Client information
Anything else we need to know?
Observed 2026-08-15 during the round-4 review of PR #9118 (posted as review 4943193833). The same fixed-path design also means cleanup's bypass audit window and the record directory are shared between concurrent same-PR runs.
中文
发生了什么？
fetch-pr 在固定路径 .qwen/tmp/review-pr-<n> 创建审查 worktree。在对 PR #9118 的 round-4 high-effort 审查中，worktree 在创建 5 分钟后被删除——删除者是另一个审查/收尾同一 PR 的会话（cleanup 旁路审计在同一时间窗口记录了 5 条无担保的同账号 PR 写入）。
失败表现不对称且无帮助：
comment-status 降级告警（所有代码事实变为 unknown）；repo-context 直接以裸 ENOENT: no such file or directory, lstat '…/review-pr-9118' 失败，未提示"worktree 缺失——请重跑 fetch-pr"；- 审查被迫从头重跑
fetch-pr，且整个生命周期仍暴露在同样竞态下（并发的同 PR fetch-pr/cleanup 随时可能再次移除 worktree）。
期望的行为？
并发同 PR 审查不得互相破坏状态：
- 按运行隔离 worktree（如随机/会话后缀
review-pr-<n>-<rand>）或对路径加锁；
- 依赖 worktree 的命令在其运行中消失时给出可操作报错（"worktree 缺失——重跑 fetch-pr"），而非裸
ENOENT。
其他
观测于 2026-08-15 PR #9118 第 4 轮审查期间（发布为 review 4943193833）。同样的固定路径设计也意味着 cleanup 的旁路审计窗口与 record 目录在并发同 PR 运行之间是共享的。
What happened?
fetch-prcreates the review worktree at a fixed path,.qwen/tmp/review-pr-<n>. During a round-4 high-effort review of PR #9118, the worktree was deleted five minutes after creation — by another session reviewing/finishing the same PR (the cleanup bypass audit recorded 5 unvouched same-account PR writes in the same time window).The failure surfaces are asymmetric and unhelpful:
comment-statusdegraded with a warning (all code facts becameunknown);repo-contexthard-failed with a bareENOENT: no such file or directory, lstat '…/review-pr-9118'that does not say "the worktree is missing — re-runfetch-pr";fetch-prfrom scratch, and remains exposed to the same race for its entire lifetime (any concurrentfetch-pr/cleanupfor the same PR number can remove the worktree again mid-run).What did you expect to happen?
Concurrent reviews of the same PR must not destroy each other's state:
review-pr-<n>-<rand>) or take a lock on the path;fetch-pr"), not a rawENOENT.Client information
packages/cli/index.tsvia tsx), reviewing PR feat(review): adopt a round-aware convergence posture for posted findings #9118 at662d98f1faAnything else we need to know?
Observed 2026-08-15 during the round-4 review of PR #9118 (posted as review 4943193833). The same fixed-path design also means
cleanup's bypass audit window and the record directory are shared between concurrent same-PR runs.中文
发生了什么？
fetch-pr在固定路径.qwen/tmp/review-pr-<n>创建审查 worktree。在对 PR #9118 的 round-4 high-effort 审查中，worktree 在创建 5 分钟后被删除——删除者是另一个审查/收尾同一 PR 的会话（cleanup 旁路审计在同一时间窗口记录了 5 条无担保的同账号 PR 写入）。失败表现不对称且无帮助：
comment-status降级告警（所有代码事实变为unknown）；repo-context直接以裸ENOENT: no such file or directory, lstat '…/review-pr-9118'失败，未提示"worktree 缺失——请重跑 fetch-pr"；fetch-pr，且整个生命周期仍暴露在同样竞态下（并发的同 PRfetch-pr/cleanup随时可能再次移除 worktree）。期望的行为？
并发同 PR 审查不得互相破坏状态：
review-pr-<n>-<rand>）或对路径加锁；ENOENT。其他
观测于 2026-08-15 PR #9118 第 4 轮审查期间（发布为 review 4943193833）。同样的固定路径设计也意味着 cleanup 的旁路审计窗口与 record 目录在并发同 PR 运行之间是共享的。