feat(hooks): add agent and tool lifecycle boundaries#18889
Conversation
d48824c to
d942194
Compare
|
Codex review: found issues before merge. Reviewed July 5, 2026, 8:46 AM ET / 12:46 UTC. Summary PR surface: Source +151, Tests +197. Total +348 across 7 files. Reproducibility: yes. at source level for the PR defects. Current main runs through Review metrics: 3 noteworthy metrics.
Merge readiness Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch. Rank-up moves:
Risk before merge
Maintainer options:
Next step before merge
Maintainer decision needed
Security Review findings
Review detailsBest possible solution: Rebase the useful lifecycle work onto the active embedded runner and adapter, preserve current client-tool slot ordering, and ship only after maintainers accept the hook names, payloads, timing, and complete tool-event coverage. Do we have a high-confidence way to reproduce the issue? Yes, at source level for the PR defects. Current main runs through Is this the best way to solve the issue? No, not as submitted. The direction is plausible, but the best fix is a current-runtime rebase plus explicit maintainer acceptance of the lifecycle hook contract and complete tool-event coverage. Full review comments:
Overall correctness: patch is incorrect AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against 601b80c5f4c1. Label changesLabel justifications:
Evidence reviewedPR surface: Source +151, Tests +197. Total +348 across 7 files. View PR surface stats
What I checked:
Likely related people:
What the crustacean ranks mean
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics. How this review workflow works
Review history (6 earlier review cycles)
|
|
Closing as superseded by the current public plugin-hook lifecycle. The old branch targets retired Thanks for the early lifecycle work, @vincentkoc. |
Why
Agent execution lacked complete lifecycle boundaries around thinking, response generation, and tool execution, reducing traceability for observability and policy systems. This PR adds those boundaries and ensures tool lifecycle hooks carry
toolCallIdcontext when available. lobster-biscuitSplit Context
This PR was accidentally closed after a messed up rebase #12583 which was originally split from closed umbrella PR #9761: #9761.
Detailed Changes
agent:thinking:start/agent:thinking:endagent:response:start/agent:response:endagent:tool:start/agent:tool:endrunAfterToolCallHookwiring for tool execution lifecycle completiontoolCallIdthrough before/after tool hook contexts where availabletoolCallIdand run after-tool hook flowRelated Links, Issues and Resolution
Greptile Summary
This PR adds complete lifecycle boundaries for agent execution (thinking, response generation, and tool execution), improving observability and traceability for policy systems. The implementation propagates
toolCallIdthrough tool lifecycle hooks and ensures consistent hook firing across different execution paths.Key improvements:
lifecycle-hooks.tsmoduleagent:thinking:start/endfire for all agent runsagent:response:start/endhooks that only fire when response output is generatedtoolCallIdtobefore_tool_callandafter_tool_callhooksrunAfterToolCallHookwiring for both success and error paths in tool executionConfidence Score: 5/5
lifecycle-hooks.tsmodule cleanly separates concerns, all hook emission paths include error handling that logs warnings without failing execution, and the test coverage validates the core lifecycle hook behavior. ThetoolCallIdpropagation is handled consistently with proper fallbacks.Last reviewed commit: d48824c