fix(macos): gate thinking-anchor reset to toolRunning only#25963
Conversation
Resetting the thinking anchor on .streamingCode can erase valid post-tool thinking intervals when a late code preview fires after tools complete. Restrict the reset to .toolRunning so the thinking duration is accurate. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: dcfad1bd2f
ℹ️ 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 newPhase == .toolRunning || newPhase == .streamingCode { | ||
| // Reset thinking anchor only when tools actually resume (not on streamingCode, | ||
| // which can fire from lingering code previews after tools complete). | ||
| if newPhase == .toolRunning { |
There was a problem hiding this comment.
Reset thinking anchor when entering streamingCode with active tools
thinkingAfterToolsStartDate is now only cleared on .toolRunning, but phase resolution returns .streamingCode before .toolRunning whenever streamingCodePreview is non-empty (even if tools are incomplete). In a multi-wave run where a code preview lingers and a new tool starts, the card can transition from post-tool thinking directly to .streamingCode and never hit .toolRunning, so the old anchor is kept and the final “thinking” duration includes time from the previous wave. This regresses duration accuracy for exactly the multi-wave case this block is handling.
Useful? React with 👍 / 👎.
|
Addressed in #25977 |
Summary
Addresses feedback from #25936
🤖 Generated with Claude Code