Best possible solution:

Land this narrow loaded-registry dedupe fix after the normal required check gates pass, preserving provider-specific matching only from the active plugin registry.

Do we have a high-confidence way to reproduce the issue?

Partly: source inspection confirms current main can fall from reply dedupe into getChannelPlugin's bundled fallback when the active registry omits the provider. I did not run the flaky 120-second shard in this read-only review, so the timeout magnitude rests on the PR's reported benchmark and CI context.

Is this the best way to solve the issue?

Yes, this appears to be the best narrow fix: dedupe already uses loaded-only target normalization, and switching the remaining matcher/thread hooks to the same loaded-registry reader removes the cold bundled load without adding a new contract. A lightweight bundled matcher would preserve more fallback behavior, but it would keep special fallback semantics in the hot path that the scoped policy is trying to avoid.

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against e82d19fb06b5.

Label changes:

• add P2: This is a bounded reply-dedupe/test-performance fix with limited blast radius and no evidence of a live user-facing outage in this PR.
• add rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🌊 off-meta tidepool and patch quality is 🐚 platinum hermit.
• add status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Not applicable: This is a MEMBER-authored maintainer PR, so the external contributor real-behavior proof gate does not apply; the PR body lists focused local validation commands and CI is the appropriate proof lane here.

Label justifications:

• P2: This is a bounded reply-dedupe/test-performance fix with limited blast radius and no evidence of a live user-facing outage in this PR.
• rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🌊 off-meta tidepool and patch quality is 🐚 platinum hermit.
• status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Not applicable: This is a MEMBER-authored maintainer PR, so the external contributor real-behavior proof gate does not apply; the PR body lists focused local validation commands and CI is the appropriate proof lane here.

PR surface:

Source +1, Tests -11. Total -10 across 2 files.

What I checked:

• Repository policy applied: Read the full root policy plus scoped channel, plugin, agent, and Telegram notes; the relevant guidance favors avoiding full bundled runtime loading in hot agent/channel paths and using loaded-only mode when callers only need registered fixtures. (src/agents/AGENTS.md:19, e82d19fb06b5)
• PR-head implementation: At PR head, reply dedupe uses getLoadedChannelPluginForRead for target normalization, reply-suppression matching, reply transport resolution, and the thread-matcher guard; the getChannelPlugin import is gone. (src/auto-reply/reply/reply-payloads-dedupe.ts:191, 8406cff6eae8)
• Current-main root cause: Current main's getChannelPlugin returns a loaded plugin or falls back to getBundledChannelPlugin, which is the fallback path this PR removes from the dedupe hot path. (src/channels/plugins/registry.ts:49, e82d19fb06b5)
• Loaded registry contract: getLoadedChannelPluginForRead reads only the active plugin channel registry state and returns undefined when the provider is not loaded, avoiding bundled materialization. (src/channels/plugins/registry-loaded-read.ts:30, e82d19fb06b5)
• Regression coverage shape: The PR test keeps provider-specific Telegram topic matching when a Telegram plugin is installed, and changes the omitted-registry case to generic route matching with no bundled Telegram mock. (src/auto-reply/reply/reply-payloads.test.ts:193, 8406cff6eae8)
• Call path checked: buildReplyPayloads calls resolveMessagingToolPayloadDedupe only after message-tool evidence exists, so the changed lookup sits on the reply payload dedupe path described by the PR. (src/auto-reply/reply/agent-runner-payloads.ts:296, e82d19fb06b5)

Likely related people:

• vincentkoc: git blame shows d28691d added the loaded channel reader, the split reply dedupe helper, and most of the current dedupe test/helper surface this PR adjusts. (role: recent loaded-registry and dedupe contributor; confidence: high; commits: d28691da97fc; files: src/channels/plugins/registry-loaded-read.ts, src/auto-reply/reply/reply-payloads-dedupe.ts, src/auto-reply/reply/reply-payloads.test.ts)
• sandieman2: git blame and PR history tie the current routed-thread guard and resolveReplyTransport dedupe path to the merged route/thread reply fix in c67dc59. (role: routed-thread dedupe behavior author; confidence: high; commits: c67dc59b02b0; files: src/auto-reply/reply/reply-payloads-dedupe.ts)
• steipete: The merged route/thread fix includes extensive adjacent reply-delivery and dedupe work attributed to steipete in the PR commit history and co-authored merge body, making this a useful routing candidate for review. (role: adjacent route/thread reply contributor; confidence: medium; commits: c67dc59b02b0; files: src/auto-reply/reply/reply-payloads-dedupe.ts, src/auto-reply/reply/agent-runner-payloads.ts)

• 🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
• 🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
• 🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
• 🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
• 🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
• 🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
• 🌊 off-meta tidepool: rating does not apply to this item.

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.

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.