feat(chat): follow agent workspace changes - #125
Conversation
Accept only worktrees registered with the current repository so workspace reports cannot expand a later turn's write sandbox. Closes #123 Co-authored-by: Codex <codex@openai.com>
|
Warning Review limit reached
Next review available in: 9 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (17)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
💡 Codex Review
Line 2580 in 4aea3ea
When the agent reports a workspace immediately before its first file-changing tool there, close_segment() has not yet parsed the marker when this diff is captured, so the capture still uses the previous checkout. close_segment() then creates the new tracker after that tool has already modified the new checkout, making those changes its baseline and permanently omitting the first edit from the inline transcript. The daemon repeats the same ordering in src/remote/turn.c:on_tool_use; both paths should process the pending segment before capturing the tool.
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
…-restartfu-xd-issues-123-8d2a1281
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 33eb754730
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| if (reported != NULL && switch_turn_workspace (turn, reported)) | ||
| text = without_workspace; |
There was a problem hiding this comment.
Switch workspaces before capturing a tool diff
When the agent reports <workspace> immediately before a file-changing tool, on_tool_use() captures and formats the tool using the old tracker and workdir before this call processes the report. For backends such as Claude, whose file_change event is deliberately deferred until after the edit completes, the old checkout contains no change; this switch then initializes the new tracker from the already-edited checkout, permanently omitting that edit from the inline diff. The daemon implementation has the same ordering, so both paths should close the segment and switch workspaces before capturing the tool diff.
Useful? React with 👍 / 👎.
| if (reported != NULL && switch_turn_workspace (turn, reported)) | ||
| text = without_workspace; |
There was a problem hiding this comment.
Hide rejected workspace control blocks
When a syntactically valid workspace report names a missing, stale, or unregistered checkout, switch_turn_workspace() returns false and this condition leaves text pointing at the original segment. The local live transcript therefore renders and stores the internal <workspace>…</workspace> markup, even though append_reply() strips the same block after a reload and the remote streaming path always hides it. Removing the control block should be independent of whether its path is accepted for retargeting.
Useful? React with 👍 / 👎.
…-restartfu-xd-issues-123-8d2a1281
Summary
<workspace>control blockTests
docker build --target test --progress plain .(21 suites pass)Closes #123