Conversation
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 019192ad67
ℹ️ 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".
| row.kind === "conversation" && | ||
| row.role === "user" && | ||
| row.initiator === "agent" && | ||
| row.senderThreadId !== null && | ||
| row.turnId !== null && | ||
| !isExcludedSender(row.senderThreadId) |
There was a problem hiding this comment.
Restrict reply attribution to accepted agent messages
When an agent steer is still pending or is rejected, it still satisfies this predicate, so collectAgentReplyRecipients treats subsequent assistant output in the already-running turn as a reply to that agent. This can relabel output that was generated for the prior requester as “Reply to …” even though the agent message was never accepted; rejected/pending agent requests should clear or preserve the prior attribution rather than become the recipient.
Useful? React with 👍 / 👎.
258f7b7 to
a9f3fc9
Compare
Add the bundled Agent messages plugin with a bb_thread_message tool. An agent messages another thread, or answers one that messaged it, through the tool, and addresses the user in its normal response. The receiver already shows "Message from"; the sender now shows the tool call as a matching "Message to" chip outside the turn's work summary. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The thread id reached the SDK's unencoded URL path, so a crafted id could traverse to other loopback API routes or bypass the self-send guard. Accept only a single id segment, and render chips only for canonical thread ids. A side chat's forwarded message reads as an agent message in its main thread; refuse to message side chats so the main agent answers the user. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Tell agents the timeline already shows messages they send and receive, so they should not announce or restate them, and to prefer bb_thread_message over bb thread tell unless they need its options. Only lift successful or in-flight calls out of the work summary, so a failed attempt stays folded. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Collapse two or more settled agent-started exchanges into one Agent conversation row, skipping live, user-steered, pending, pinned, and side-chat exchanges. Explain in the tool's instructions what bb_thread_message and bb thread tell each offer, keep that out of the core bb-cli skill, and keep the tool result to delivery status. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Write the tool instructions as one short imperative paragraph like core bb tool guidance, listing only the bb thread tell options agents need. Keep GeneratedConversationMessage's existing layout, inline the side-chat check, and collapse overlapping test cases into tables. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Treat the live row and the first unread row as pinned, so one rule keeps those exchanges expanded instead of separate active-turn and divider handling. Render the Message to row in ThreadTimelineRows from its contexts like ConversationRow, and print grouped rows flat in CLI text. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The bb-guide introduction applies to every agent, so the exception for answering an agent now lives in the plugin's own instructions and the core line is unchanged. The tool refuses recipients that run with broader permissions than the sender, because bb tools skip the sender's approvals. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…dgements Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…er receives them Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
a96bc1e to
ec663e6
Compare
Human comments
What was wrong
Agents had no explicit way to address another agent, so every answer meant for an agent landed in the user's timeline as an ordinary reply. In busy coordinating threads this cluttered the timeline and buried the messages meant for the user: in one, 60 of 238 turns were started by another agent's message, and 52 of them ended with a visible reply. Outgoing messages were
bb thread tellshell commands, hidden in the turn's work summary.What changed
bb_thread_messagetool from the built-in Agent messages plugin, which is off by default.bb_thread_message, because only it shows the message in the sending thread. They reservebb thread tellfor its--mode queue,--send-at,--plan, and attachment options.bb thread tellbehaves as before.How you verified
128b7b92c6: 31 checks passed and 3 were skipped.Before:
cd12e7a9df. After:258f7b703c. Captured before the rebase onto mainc201f6490a, whose two new commits don't touch the timeline. Same dev database, threads, and viewports, captured at 2×.P2 follow-ups, not in this PR
bb:, so they show no "Message to" row.bb thread logprints a sent message as a generic tool row.bb_thread_messagefirst and borrow the row.bb thread tell.BB-Thread-ID: thr_4u5mgu9qe7
🤖 Generated with Claude Code