Discord: add PluralKit sender identity resolver by thewilloftheshadow · Pull Request #5838 · openclaw/openclaw

thewilloftheshadow · 2026-02-01T01:42:46Z

Summary

add PluralKit API support and sender identity resolution for Discord
propagate PK-aware identity to allowlists, history, and reply context
document PK config/allowlist usage and lookup limits

Testing

not run (not requested)

Greptile Overview

Greptile Summary

This PR adds PluralKit integration for Discord by introducing a PK message lookup (src/discord/pluralkit.ts) and a unified sender identity model (src/discord/monitor/sender-identity.ts). The Discord message preflight path now optionally queries PK and uses the resolved sender identity for allowlist checks and history sender labels, and config/docs are extended to support channels.discord.pluralkit.{enabled,token}.

Main issue found: the new PK-aware identity isn’t fully propagated into the inbound context consumed downstream. processDiscordMessage still populates SenderId/SenderTag from the original Discord author, so per-sender behavior and any downstream logic will still “see” the proxy identity rather than the PK member.

Also flagged: the self-message guard now depends on author.bot, which could weaken loop prevention if that flag is ever missing/false; and reply-context generation currently has no path to resolve PK identity for referenced messages despite the stated goal to make reply context PK-aware.

Confidence Score: 3/5

This PR is reasonably safe to merge, but has a correctness gap where PK identity is not consistently propagated.
Core changes are additive and well-scoped (new PK fetch helper, new sender identity helper, config/schema updates, and tests). However, processDiscordMessage still uses the original Discord author for SenderId/SenderTag, which undermines the stated feature goal and can affect downstream behavior. There is also a potential robustness regression in the self-message loop guard depending on author.bot.
src/discord/monitor/message-handler.process.ts; src/discord/monitor/message-handler.preflight.ts; src/discord/monitor/reply-context.ts

greptile-apps

_{4 files reviewed, 4 comments}

_{Edit Code Review Agent Settings | Greptile}

greptile-apps · 2026-02-01T01:45:01Z

src/discord/monitor/reply-context.ts

+  const sender = resolveDiscordSenderIdentity({
+    author: referenced.author,
+    pluralkitInfo: null,
+  });
+  const fromLabel = referenced.author ? buildDirectLabel(referenced.author, sender.tag) : "Unknown";
+  const body = `${referencedText}\n[discord message id: ${referenced.id} channel: ${referenced.channelId} from: ${sender.tag ?? sender.label} user id:${sender.id}]`;
  return formatAgentEnvelope({


[P2] Reply context still cannot resolve PK identity

resolveReplyContext always calls resolveDiscordSenderIdentity with pluralkitInfo: null, so replies to PK-proxied messages will continue to attribute the referenced message to the Discord webhook/bot identity (or whatever formatDiscordUserTag produces), not the PK member.

If the intent is “PK-aware reply context” (per PR description), this likely needs the same PK lookup path used in preflightDiscordMessage, or at least to thread the already-resolved sender into reply context construction.

Prompt To Fix With AI

This is a comment left during a code review. Path: src/discord/monitor/reply-context.ts Line: 22:28 Comment: [P2] Reply context still cannot resolve PK identity `resolveReplyContext` always calls `resolveDiscordSenderIdentity` with `pluralkitInfo: null`, so replies to PK-proxied messages will continue to attribute the referenced message to the Discord webhook/bot identity (or whatever `formatDiscordUserTag` produces), not the PK member. If the intent is “PK-aware reply context” (per PR description), this likely needs the same PK lookup path used in `preflightDiscordMessage`, or at least to thread the already-resolved `sender` into reply context construction. How can I resolve this? If you propose a fix, please make it concise.

greptile-apps · 2026-02-01T01:45:02Z

src/discord/pluralkit.ts

+  const headers: Record<string, string> = {};
+  if (params.config.token?.trim()) {
+    headers.Authorization = params.config.token.trim();
+  }
+  const res = await fetchImpl(`${PLURALKIT_API_BASE}/messages/${params.messageId}`, {
+    headers,
+  });


[P2] Always sending headers: {} may behave differently than omitting headers

When no token is configured, this still passes an empty headers object to fetch. Some fetch implementations treat headers: {} differently than headers being omitted (e.g., around defaults/normalization).

Not necessarily broken, but if resolveFetch can return non-standard implementations, it may be safer to only include the headers option when there’s actually an Authorization header.

Prompt To Fix With AI

This is a comment left during a code review. Path: src/discord/pluralkit.ts Line: 42:48 Comment: [P2] Always sending `headers: {}` may behave differently than omitting headers When no token is configured, this still passes an empty `headers` object to `fetch`. Some fetch implementations treat `headers: {}` differently than `headers` being omitted (e.g., around defaults/normalization). Not necessarily broken, but if `resolveFetch` can return non-standard implementations, it may be safer to only include the `headers` option when there’s actually an Authorization header. How can I resolve this? If you propose a fix, please make it concise.

greptile-apps · 2026-02-01T01:45:04Z

Additional Comments (2)

src/discord/monitor/message-handler.process.ts
[P0] PK sender identity not propagated to inbound context

processDiscordMessage now computes senderLabel = sender.label, but still populates finalizeInboundContext with the original Discord author fields (SenderName, SenderId, SenderTag). This means allowlists/history are PK-aware, but the agent/runtime context and any per-sender logic downstream will still see the Discord bot user (the proxy) rather than the PK member.

This shows up in src/discord/monitor/message-handler.process.ts:271-275 and should likely use the already-computed sender identity (id/name/tag) instead of author/formatDiscordUserTag(author).

Prompt To Fix With AI

This is a comment left during a code review.
Path: src/discord/monitor/message-handler.process.ts
Line: 122:125

Comment:
[P0] PK sender identity not propagated to inbound context

`processDiscordMessage` now computes `senderLabel = sender.label`, but still populates `finalizeInboundContext` with the original Discord author fields (`SenderName`, `SenderId`, `SenderTag`). This means allowlists/history are PK-aware, but the agent/runtime context and any per-sender logic downstream will still see the Discord bot user (the proxy) rather than the PK member.

This shows up in `src/discord/monitor/message-handler.process.ts:271-275` and should likely use the already-computed `sender` identity (id/name/tag) instead of `author`/`formatDiscordUserTag(author)`.

How can I resolve this? If you propose a fix, please make it concise.

src/discord/monitor/message-handler.preflight.ts
[P1] Self-message loop prevention no longer covers non-bot authored messages

The self-reply guard is now gated by author.bot && author.id === botUserId. If the Discord library ever delivers a message from the bot account where author.bot is missing/false (e.g. partial user objects, API changes, or mis-typed fields), this will stop preventing self-reply loops.

Previously the code returned early on author.id === botUserId regardless of author.bot. Consider restoring the author.id === botUserId check without depending on the bot flag.

Prompt To Fix With AI

This is a comment left during a code review.
Path: src/discord/monitor/message-handler.preflight.ts
Line: 270:275

Comment:
[P1] Self-message loop prevention no longer covers non-bot authored messages

The self-reply guard is now gated by `author.bot && author.id === botUserId`. If the Discord library ever delivers a message from the bot account where `author.bot` is missing/false (e.g. partial user objects, API changes, or mis-typed fields), this will stop preventing self-reply loops.

Previously the code returned early on `author.id === botUserId` regardless of `author.bot`. Consider restoring the `author.id === botUserId` check without depending on the `bot` flag.

How can I resolve this? If you propose a fix, please make it concise.

…eshadow

…eshadow)

github-actions · 2026-02-01T01:49:59Z

⚠️ Formal models conformance drift detected

The formal models extracted constants (generated/*) do not match this openclaw PR.

This check is informational (not blocking merges yet).
See the formal-models-conformance-drift artifact for the diff.

If this change is intentional, follow up by updating the formal models repo or regenerating the extracted artifacts there.

thewilloftheshadow · 2026-02-01T01:50:38Z

Landed via temp rebase onto main.

Related tests: pnpm vitest run --config vitest.unit.config.ts src/discord/monitor.test.ts src/discord/pluralkit.test.ts
Land commit: a1cf76e
Merge commit: 8e2b17e

Thanks @thewilloftheshadow!

orionnelson · 2026-02-01T02:01:51Z

@thewilloftheshadow Might be a small bug in this or I pulled wrong
0.534 A2UI sources missing; keeping prebuilt bundle.
12.32 src/discord/monitor/message-handler.preflight.ts(58,3): error TS2459: Module '"./message-handler.preflight.types.js"' declares 'DiscordSenderIdentity' locally, but it is not exported.
12.39 ELIFECYCLE Command failed with exit code 1.

thewilloftheshadow · 2026-02-01T02:03:05Z