feat(plugin-sdk): add reply payload sending hook#82823
Conversation
|
Codex review: needs changes before merge. Reviewed May 29, 2026, 1:50 AM ET / 05:50 UTC. Summary PR surface: Source +514, Tests +999, Docs +10, Generated 0. Total +1523 across 30 files. Reproducibility: yes. for the review finding: source inspection shows the custom Review metrics: 1 noteworthy metric.
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:
Copy recommended automerge instructionNext step before merge
Security Review findings
Review detailsBest possible solution: Land a rebased branch only after the custom Do we have a high-confidence way to reproduce the issue? Yes for the review finding: source inspection shows the custom Is this the best way to solve the issue? No as-is: the new normalized payload hook is a plausible SDK seam, but it should preserve canonical Full review comments:
Overall correctness: patch is incorrect AGENTS.md: found and applied where relevant. Codex review notes: model gpt-5.5, reasoning high; reviewed against 621db8f0b1b4. Label changesLabel changes:
Label justifications:
Evidence reviewedPR surface: Source +514, Tests +999, Docs +10, Generated 0. Total +1523 across 30 files. View PR surface stats
Acceptance criteria:
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
|
|
@clawsweeper re-review Thanks for the review — the P2 issue has been fixed in commit Before: After: Both Real Telegram behavior proof: I'll add a follow-up comment with a test plugin demonstrating Telegram inline buttons on a normal assistant reply via |
|
Real behavior proof — test plugin for maintainers: // Minimal plugin that demonstrates reply_payload_sending adding Telegram buttons
export default definePlugin({
name: 'test-telegram-buttons',
hooks: {
reply_payload_sending: async ({ payload, channel }) => {
if (channel !== 'telegram') return;
return {
payload: {
...payload,
presentation: {
blocks: [
{
type: 'buttons',
buttons: [
{ label: 'Proceed', value: 'action:proceed' },
{ label: 'Status', value: 'action:status' }
]
}
]
}
}
};
}
}
});Verification steps:
I can provide a screen recording from my local instance if needed — the hook composition fix in |
|
🦞🧹 I asked ClawSweeper to review this item again. Re-review progress:
|
|
Real behavior proof — terminal output: Note: Full unit test suite ( Live Telegram proof: The test plugin in this branch adds |
|
@clawsweeper re-review Terminal proof added in comment above showing:
Please re-review. |
|
Fixed CI failure in commit |
|
🦞🧹 I asked ClawSweeper to review this item again. Re-review progress:
|
0cae438 to
f944a04
Compare
|
Rebased on latest Behavior addressed: same as above, plus the direct internal-source transcript mirror now records the delivered post-hook payload instead of stale pre-hook metadata when Real environment tested: local OpenClaw checkout with repo wrappers after the rebase; GitHub Actions are running on the pushed head SHA. Exact steps or command run after this patch:
Evidence after fix: Observed result after fix: delivery hooks, queue recovery, media scoping, routed suppression, canonical What was not tested: full |
Summary
Why
Today plugin authors can:
But there is no hook that exposes the actual normalized outbound `ReplyPayload` before channel delivery. That makes clean plugin-only features like attaching Telegram inline buttons to normal assistant replies hard or impossible without core patches.
This change adds a focused seam for that use case while reusing the existing before-deliver phase in the reply dispatcher.
What changed
Verification
Targeted local verification completed:
Repo-wide `pnpm build && pnpm check && pnpm test` was not run end-to-end on this machine for this PR; validation here was focused on the touched hook, dispatch, docs, and real Telegram behavior path.
Live validation
Real behavior proof
Behavior or issue addressed: Plugin authors need a way to mutate normalized outbound reply payloads before channel delivery so plugin-only features such as Telegram inline buttons can be added without core channel-specific patches.
Real environment tested: Local OpenClaw gateway running against a real Telegram bot and Telegram Desktop on the host machine, using the installed local `telegram-final-buttons` plugin.
Exact steps or command run after this patch:
Evidence after fix: Gateway logs showed the live `telegram-final-buttons` plugin attaching buttons to a Telegram final reply and Telegram delivering the reply successfully. A local Telegram Desktop screenshot was captured showing the rendered inline buttons.
Observed result after fix: The Telegram bot reply rendered native inline buttons in the real client, including `Proceed`, `Status`, and `Recommendation`.
What was not tested: Fresh linked-install validation from the temporary fork-side demo package was not the final proof path; the real behavior proof used the already-installed local plugin path instead.
AI assistance
This PR was AI-assisted. I used Codex to help implement, test, validate, and iterate on the change, and I reviewed the resulting code and behavior locally before submission.
Notes