← Back to PRs

#10260: fix(outbound): enforce sendPolicy on system notifications (#6301)

by nu-gui open 2026-02-06 08:24 View on GitHub →
stale
## Summary - Abort reply notifications bypassed sendPolicy deny rules, causing system messages to leak to channels that should be blocked - Add a sendPolicy check in the abort reply path of `dispatchReplyFromConfig()` before dispatching abort replies via `routeReply()` or `dispatcher.sendFinalReply()` - When sendPolicy returns "deny", the abort reply is suppressed and the function returns early Fixes #6301 ## Test plan - [x] All 12 existing dispatch-from-config tests pass - [x] `pnpm check` passes (0 warnings, 0 errors) - [x] Manual verification: abort replies are blocked when sendPolicy is set to deny <!-- greptile_comment --> <h2>Greptile Overview</h2> <h3>Greptile Summary</h3> - Adds a `resolveSendPolicy` check to the fast-abort/abort-reply path in `dispatchReplyFromConfig()` to prevent system abort notifications from bypassing deny rules. - Loads the session store entry for the current session key to evaluate send policy using both config-wide rules and per-session overrides. - When policy resolves to `deny`, suppresses the abort reply and returns early after marking the message processed/idle (diagnostics-aware). <h3>Confidence Score: 4/5</h3> - This PR is close to safe to merge, but has a correctness edge case in how it looks up the session entry for sendPolicy evaluation. - Change is localized and matches existing sendPolicy enforcement patterns, but the new abort-path store lookup doesn’t apply the same sessionKey normalization used elsewhere in the file, which can cause policy to be evaluated without the intended session entry. - src/auto-reply/reply/dispatch-from-config.ts <!-- greptile_other_comments_section --> <!-- /greptile_comment -->

Most Similar PRs