415 lines
14 KiB
TypeScript
Raw Normal View History

2026-01-30 03:15:10 +01:00
import type { ChannelAccountSnapshot, ChannelPlugin, OpenClawConfig } from "openclaw/plugin-sdk";
2026-01-18 03:17:30 +00:00
import {
applyAccountNameToChannelSection,
buildChannelConfigSchema,
2026-01-19 18:50:22 -08:00
collectBlueBubblesStatusIssues,
2026-01-18 03:17:30 +00:00
DEFAULT_ACCOUNT_ID,
deleteAccountFromConfigSection,
formatPairingApproveHint,
migrateBaseNameToDefaultAccount,
normalizeAccountId,
PAIRING_APPROVED_MESSAGE,
resolveBlueBubblesGroupRequireMention,
2026-01-24 15:35:05 +13:00
resolveBlueBubblesGroupToolPolicy,
2026-01-18 03:17:30 +00:00
setAccountEnabledInConfigSection,
2026-01-30 03:15:10 +01:00
} from "openclaw/plugin-sdk";
2026-01-18 03:17:30 +00:00
import {
listBlueBubblesAccountIds,
type ResolvedBlueBubblesAccount,
resolveBlueBubblesAccount,
resolveDefaultBlueBubblesAccountId,
} from "./accounts.js";
import { bluebubblesMessageActions } from "./actions.js";
2026-01-18 03:17:30 +00:00
import { BlueBubblesConfigSchema } from "./config-schema.js";
import { sendBlueBubblesMedia } from "./media-send.js";
import { resolveBlueBubblesMessageId } from "./monitor.js";
import { monitorBlueBubblesProvider, resolveWebhookPathFromConfig } from "./monitor.js";
import { blueBubblesOnboardingAdapter } from "./onboarding.js";
import { probeBlueBubbles, type BlueBubblesProbe } from "./probe.js";
2026-01-18 03:17:30 +00:00
import { sendMessageBlueBubbles } from "./send.js";
import {
fix(bluebubbles): route phone-number targets to direct chats; prevent internal IDs leaking in cross-context prefix (#1751) * fix(bluebubbles): prefer DM resolution + hide routing markers * fix(bluebubbles): prevent message routing to group chats when targeting phone numbers When sending a message to a phone number like +12622102921, the resolveChatGuidForTarget function was finding and returning a GROUP CHAT containing that phone number instead of a direct DM chat. The bug was in the participantMatch fallback logic which matched ANY chat containing the phone number as a participant, including groups. This fix adds a check to ensure participantMatch only considers DM chats (identified by ';-;' separator in the chat GUID). Group chats (identified by ';+;' separator) are now explicitly excluded from handle-based matching. If a phone number only exists in a group chat (no direct DM exists), the function now correctly returns null, which causes the send to fail with a clear error rather than accidentally messaging a group. Added test case to verify this behavior. * feat(bluebubbles): auto-create new DM chats when sending to unknown phone numbers When sending to a phone number that doesn't have an existing chat, instead of failing with 'chatGuid not found', now automatically creates a new chat using the /api/v1/chat/new endpoint. - Added createNewChatWithMessage() helper function - When resolveChatGuidForTarget returns null for a handle target, uses the new chat endpoint with addresses array and message - Includes helpful error message if Private API isn't enabled - Only applies to handle targets (phone numbers), not group chats * fix(bluebubbles): hide internal routing metadata in cross-context markers When sending cross-context messages via BlueBubbles, the origin marker was exposing internal chat_guid routing info like '[from bluebubbles:chat_guid:any;-;+19257864429]'. This adds a formatTargetDisplay() function to the BlueBubbles plugin that: - Extracts phone numbers from chat_guid formats (iMessage;-;+1234567890 -> +1234567890) - Normalizes handles for clean display - Avoids returning raw chat_guid formats containing internal routing metadata Now cross-context markers show clean identifiers like '[from +19257864429]' instead of exposing internal routing details to recipients. * fix: prevent cross-context decoration on direct message tool sends Two fixes: 1. Cross-context decoration (e.g., '[from +19257864429]' prefix) was being added to ALL messages sent to a different target, even when the agent was just composing a new message via the message tool. This decoration should only be applied when forwarding/relaying messages between chats. Fix: Added skipCrossContextDecoration flag to ChannelThreadingToolContext. The message tool now sets this flag to true, so direct sends don't get decorated. The buildCrossContextDecoration function checks this flag and returns null when set. 2. Aborted requests were still completing because the abort signal wasn't being passed through the message tool execution chain. Fix: Added abortSignal propagation from message tool → runMessageAction → executeSendAction → sendMessage → deliverOutboundPayloads. Added abort checks at key points in the chain to fail fast when aborted. Files changed: - src/channels/plugins/types.core.ts: Added skipCrossContextDecoration field - src/infra/outbound/outbound-policy.ts: Check skip flag before decorating - src/agents/tools/message-tool.ts: Set skip flag, accept and pass abort signal - src/infra/outbound/message-action-runner.ts: Pass abort signal through - src/infra/outbound/outbound-send-service.ts: Check and pass abort signal - src/infra/outbound/message.ts: Pass abort signal to delivery * fix(bluebubbles): preserve friendly display names in formatTargetDisplay
2026-01-25 02:03:08 -08:00
extractHandleFromChatGuid,
looksLikeBlueBubblesTargetId,
normalizeBlueBubblesHandle,
normalizeBlueBubblesMessagingTarget,
fix(bluebubbles): route phone-number targets to direct chats; prevent internal IDs leaking in cross-context prefix (#1751) * fix(bluebubbles): prefer DM resolution + hide routing markers * fix(bluebubbles): prevent message routing to group chats when targeting phone numbers When sending a message to a phone number like +12622102921, the resolveChatGuidForTarget function was finding and returning a GROUP CHAT containing that phone number instead of a direct DM chat. The bug was in the participantMatch fallback logic which matched ANY chat containing the phone number as a participant, including groups. This fix adds a check to ensure participantMatch only considers DM chats (identified by ';-;' separator in the chat GUID). Group chats (identified by ';+;' separator) are now explicitly excluded from handle-based matching. If a phone number only exists in a group chat (no direct DM exists), the function now correctly returns null, which causes the send to fail with a clear error rather than accidentally messaging a group. Added test case to verify this behavior. * feat(bluebubbles): auto-create new DM chats when sending to unknown phone numbers When sending to a phone number that doesn't have an existing chat, instead of failing with 'chatGuid not found', now automatically creates a new chat using the /api/v1/chat/new endpoint. - Added createNewChatWithMessage() helper function - When resolveChatGuidForTarget returns null for a handle target, uses the new chat endpoint with addresses array and message - Includes helpful error message if Private API isn't enabled - Only applies to handle targets (phone numbers), not group chats * fix(bluebubbles): hide internal routing metadata in cross-context markers When sending cross-context messages via BlueBubbles, the origin marker was exposing internal chat_guid routing info like '[from bluebubbles:chat_guid:any;-;+19257864429]'. This adds a formatTargetDisplay() function to the BlueBubbles plugin that: - Extracts phone numbers from chat_guid formats (iMessage;-;+1234567890 -> +1234567890) - Normalizes handles for clean display - Avoids returning raw chat_guid formats containing internal routing metadata Now cross-context markers show clean identifiers like '[from +19257864429]' instead of exposing internal routing details to recipients. * fix: prevent cross-context decoration on direct message tool sends Two fixes: 1. Cross-context decoration (e.g., '[from +19257864429]' prefix) was being added to ALL messages sent to a different target, even when the agent was just composing a new message via the message tool. This decoration should only be applied when forwarding/relaying messages between chats. Fix: Added skipCrossContextDecoration flag to ChannelThreadingToolContext. The message tool now sets this flag to true, so direct sends don't get decorated. The buildCrossContextDecoration function checks this flag and returns null when set. 2. Aborted requests were still completing because the abort signal wasn't being passed through the message tool execution chain. Fix: Added abortSignal propagation from message tool → runMessageAction → executeSendAction → sendMessage → deliverOutboundPayloads. Added abort checks at key points in the chain to fail fast when aborted. Files changed: - src/channels/plugins/types.core.ts: Added skipCrossContextDecoration field - src/infra/outbound/outbound-policy.ts: Check skip flag before decorating - src/agents/tools/message-tool.ts: Set skip flag, accept and pass abort signal - src/infra/outbound/message-action-runner.ts: Pass abort signal through - src/infra/outbound/outbound-send-service.ts: Check and pass abort signal - src/infra/outbound/message.ts: Pass abort signal to delivery * fix(bluebubbles): preserve friendly display names in formatTargetDisplay
2026-01-25 02:03:08 -08:00
parseBlueBubblesTarget,
} from "./targets.js";
2026-01-18 03:17:30 +00:00
const meta = {
id: "bluebubbles",
label: "BlueBubbles",
selectionLabel: "BlueBubbles (macOS app)",
detailLabel: "BlueBubbles",
docsPath: "/channels/bluebubbles",
docsLabel: "bluebubbles",
blurb: "iMessage via the BlueBubbles mac app + REST API.",
systemImage: "bubble.left.and.text.bubble.right",
aliases: ["bb"],
2026-01-18 03:17:30 +00:00
order: 75,
preferOver: ["imessage"],
2026-01-18 03:17:30 +00:00
};
export const bluebubblesPlugin: ChannelPlugin<ResolvedBlueBubblesAccount> = {
id: "bluebubbles",
meta,
capabilities: {
chatTypes: ["direct", "group"],
media: true,
2026-01-18 03:17:30 +00:00
reactions: true,
edit: true,
unsend: true,
reply: true,
effects: true,
groupManagement: true,
2026-01-18 03:17:30 +00:00
},
groups: {
resolveRequireMention: resolveBlueBubblesGroupRequireMention,
2026-01-24 15:35:05 +13:00
resolveToolPolicy: resolveBlueBubblesGroupToolPolicy,
},
threading: {
buildToolContext: ({ context, hasRepliedRef }) => ({
currentChannelId: context.To?.trim() || undefined,
currentThreadTs: context.ReplyToIdFull ?? context.ReplyToId,
hasRepliedRef,
}),
},
2026-01-18 03:17:30 +00:00
reload: { configPrefixes: ["channels.bluebubbles"] },
configSchema: buildChannelConfigSchema(BlueBubblesConfigSchema),
2026-01-19 18:06:30 -08:00
onboarding: blueBubblesOnboardingAdapter,
2026-01-18 03:17:30 +00:00
config: {
2026-01-31 22:13:48 +09:00
listAccountIds: (cfg) => listBlueBubblesAccountIds(cfg),
resolveAccount: (cfg, accountId) => resolveBlueBubblesAccount({ cfg: cfg, accountId }),
defaultAccountId: (cfg) => resolveDefaultBlueBubblesAccountId(cfg),
2026-01-18 03:17:30 +00:00
setAccountEnabled: ({ cfg, accountId, enabled }) =>
setAccountEnabledInConfigSection({
2026-01-31 22:13:48 +09:00
cfg: cfg,
2026-01-18 03:17:30 +00:00
sectionKey: "bluebubbles",
accountId,
enabled,
allowTopLevel: true,
}),
deleteAccount: ({ cfg, accountId }) =>
deleteAccountFromConfigSection({
2026-01-31 22:13:48 +09:00
cfg: cfg,
2026-01-18 03:17:30 +00:00
sectionKey: "bluebubbles",
accountId,
clearBaseFields: ["serverUrl", "password", "name", "webhookPath"],
}),
isConfigured: (account) => account.configured,
describeAccount: (account): ChannelAccountSnapshot => ({
accountId: account.accountId,
name: account.name,
enabled: account.enabled,
configured: account.configured,
baseUrl: account.baseUrl,
}),
resolveAllowFrom: ({ cfg, accountId }) =>
2026-01-31 22:13:48 +09:00
(resolveBlueBubblesAccount({ cfg: cfg, accountId }).config.allowFrom ?? []).map((entry) =>
String(entry),
),
2026-01-18 03:17:30 +00:00
formatAllowFrom: ({ allowFrom }) =>
allowFrom
.map((entry) => String(entry).trim())
.filter(Boolean)
.map((entry) => entry.replace(/^bluebubbles:/i, ""))
.map((entry) => normalizeBlueBubblesHandle(entry)),
},
actions: bluebubblesMessageActions,
security: {
resolveDmPolicy: ({ cfg, accountId, account }) => {
const resolvedAccountId = accountId ?? account.accountId ?? DEFAULT_ACCOUNT_ID;
2026-01-31 22:13:48 +09:00
const useAccountPath = Boolean(cfg.channels?.bluebubbles?.accounts?.[resolvedAccountId]);
2026-01-18 03:17:30 +00:00
const basePath = useAccountPath
? `channels.bluebubbles.accounts.${resolvedAccountId}.`
: "channels.bluebubbles.";
return {
policy: account.config.dmPolicy ?? "pairing",
allowFrom: account.config.allowFrom ?? [],
policyPath: `${basePath}dmPolicy`,
allowFromPath: basePath,
approveHint: formatPairingApproveHint("bluebubbles"),
normalizeEntry: (raw) => normalizeBlueBubblesHandle(raw.replace(/^bluebubbles:/i, "")),
};
},
collectWarnings: ({ account }) => {
const groupPolicy = account.config.groupPolicy ?? "allowlist";
2026-01-31 22:13:48 +09:00
if (groupPolicy !== "open") {
return [];
}
2026-01-18 03:17:30 +00:00
return [
`- BlueBubbles groups: groupPolicy="open" allows any member to trigger the bot. Set channels.bluebubbles.groupPolicy="allowlist" + channels.bluebubbles.groupAllowFrom to restrict senders.`,
];
},
},
messaging: {
normalizeTarget: normalizeBlueBubblesMessagingTarget,
targetResolver: {
looksLikeId: looksLikeBlueBubblesTargetId,
hint: "<handle|chat_guid:GUID|chat_id:ID|chat_identifier:ID>",
},
fix(bluebubbles): route phone-number targets to direct chats; prevent internal IDs leaking in cross-context prefix (#1751) * fix(bluebubbles): prefer DM resolution + hide routing markers * fix(bluebubbles): prevent message routing to group chats when targeting phone numbers When sending a message to a phone number like +12622102921, the resolveChatGuidForTarget function was finding and returning a GROUP CHAT containing that phone number instead of a direct DM chat. The bug was in the participantMatch fallback logic which matched ANY chat containing the phone number as a participant, including groups. This fix adds a check to ensure participantMatch only considers DM chats (identified by ';-;' separator in the chat GUID). Group chats (identified by ';+;' separator) are now explicitly excluded from handle-based matching. If a phone number only exists in a group chat (no direct DM exists), the function now correctly returns null, which causes the send to fail with a clear error rather than accidentally messaging a group. Added test case to verify this behavior. * feat(bluebubbles): auto-create new DM chats when sending to unknown phone numbers When sending to a phone number that doesn't have an existing chat, instead of failing with 'chatGuid not found', now automatically creates a new chat using the /api/v1/chat/new endpoint. - Added createNewChatWithMessage() helper function - When resolveChatGuidForTarget returns null for a handle target, uses the new chat endpoint with addresses array and message - Includes helpful error message if Private API isn't enabled - Only applies to handle targets (phone numbers), not group chats * fix(bluebubbles): hide internal routing metadata in cross-context markers When sending cross-context messages via BlueBubbles, the origin marker was exposing internal chat_guid routing info like '[from bluebubbles:chat_guid:any;-;+19257864429]'. This adds a formatTargetDisplay() function to the BlueBubbles plugin that: - Extracts phone numbers from chat_guid formats (iMessage;-;+1234567890 -> +1234567890) - Normalizes handles for clean display - Avoids returning raw chat_guid formats containing internal routing metadata Now cross-context markers show clean identifiers like '[from +19257864429]' instead of exposing internal routing details to recipients. * fix: prevent cross-context decoration on direct message tool sends Two fixes: 1. Cross-context decoration (e.g., '[from +19257864429]' prefix) was being added to ALL messages sent to a different target, even when the agent was just composing a new message via the message tool. This decoration should only be applied when forwarding/relaying messages between chats. Fix: Added skipCrossContextDecoration flag to ChannelThreadingToolContext. The message tool now sets this flag to true, so direct sends don't get decorated. The buildCrossContextDecoration function checks this flag and returns null when set. 2. Aborted requests were still completing because the abort signal wasn't being passed through the message tool execution chain. Fix: Added abortSignal propagation from message tool → runMessageAction → executeSendAction → sendMessage → deliverOutboundPayloads. Added abort checks at key points in the chain to fail fast when aborted. Files changed: - src/channels/plugins/types.core.ts: Added skipCrossContextDecoration field - src/infra/outbound/outbound-policy.ts: Check skip flag before decorating - src/agents/tools/message-tool.ts: Set skip flag, accept and pass abort signal - src/infra/outbound/message-action-runner.ts: Pass abort signal through - src/infra/outbound/outbound-send-service.ts: Check and pass abort signal - src/infra/outbound/message.ts: Pass abort signal to delivery * fix(bluebubbles): preserve friendly display names in formatTargetDisplay
2026-01-25 02:03:08 -08:00
formatTargetDisplay: ({ target, display }) => {
const shouldParseDisplay = (value: string): boolean => {
2026-01-31 22:13:48 +09:00
if (looksLikeBlueBubblesTargetId(value)) {
return true;
}
fix(bluebubbles): route phone-number targets to direct chats; prevent internal IDs leaking in cross-context prefix (#1751) * fix(bluebubbles): prefer DM resolution + hide routing markers * fix(bluebubbles): prevent message routing to group chats when targeting phone numbers When sending a message to a phone number like +12622102921, the resolveChatGuidForTarget function was finding and returning a GROUP CHAT containing that phone number instead of a direct DM chat. The bug was in the participantMatch fallback logic which matched ANY chat containing the phone number as a participant, including groups. This fix adds a check to ensure participantMatch only considers DM chats (identified by ';-;' separator in the chat GUID). Group chats (identified by ';+;' separator) are now explicitly excluded from handle-based matching. If a phone number only exists in a group chat (no direct DM exists), the function now correctly returns null, which causes the send to fail with a clear error rather than accidentally messaging a group. Added test case to verify this behavior. * feat(bluebubbles): auto-create new DM chats when sending to unknown phone numbers When sending to a phone number that doesn't have an existing chat, instead of failing with 'chatGuid not found', now automatically creates a new chat using the /api/v1/chat/new endpoint. - Added createNewChatWithMessage() helper function - When resolveChatGuidForTarget returns null for a handle target, uses the new chat endpoint with addresses array and message - Includes helpful error message if Private API isn't enabled - Only applies to handle targets (phone numbers), not group chats * fix(bluebubbles): hide internal routing metadata in cross-context markers When sending cross-context messages via BlueBubbles, the origin marker was exposing internal chat_guid routing info like '[from bluebubbles:chat_guid:any;-;+19257864429]'. This adds a formatTargetDisplay() function to the BlueBubbles plugin that: - Extracts phone numbers from chat_guid formats (iMessage;-;+1234567890 -> +1234567890) - Normalizes handles for clean display - Avoids returning raw chat_guid formats containing internal routing metadata Now cross-context markers show clean identifiers like '[from +19257864429]' instead of exposing internal routing details to recipients. * fix: prevent cross-context decoration on direct message tool sends Two fixes: 1. Cross-context decoration (e.g., '[from +19257864429]' prefix) was being added to ALL messages sent to a different target, even when the agent was just composing a new message via the message tool. This decoration should only be applied when forwarding/relaying messages between chats. Fix: Added skipCrossContextDecoration flag to ChannelThreadingToolContext. The message tool now sets this flag to true, so direct sends don't get decorated. The buildCrossContextDecoration function checks this flag and returns null when set. 2. Aborted requests were still completing because the abort signal wasn't being passed through the message tool execution chain. Fix: Added abortSignal propagation from message tool → runMessageAction → executeSendAction → sendMessage → deliverOutboundPayloads. Added abort checks at key points in the chain to fail fast when aborted. Files changed: - src/channels/plugins/types.core.ts: Added skipCrossContextDecoration field - src/infra/outbound/outbound-policy.ts: Check skip flag before decorating - src/agents/tools/message-tool.ts: Set skip flag, accept and pass abort signal - src/infra/outbound/message-action-runner.ts: Pass abort signal through - src/infra/outbound/outbound-send-service.ts: Check and pass abort signal - src/infra/outbound/message.ts: Pass abort signal to delivery * fix(bluebubbles): preserve friendly display names in formatTargetDisplay
2026-01-25 02:03:08 -08:00
return /^(bluebubbles:|chat_guid:|chat_id:|chat_identifier:)/i.test(value);
};
// Helper to extract a clean handle from any BlueBubbles target format
const extractCleanDisplay = (value: string | undefined): string | null => {
const trimmed = value?.trim();
2026-01-31 22:13:48 +09:00
if (!trimmed) {
return null;
}
fix(bluebubbles): route phone-number targets to direct chats; prevent internal IDs leaking in cross-context prefix (#1751) * fix(bluebubbles): prefer DM resolution + hide routing markers * fix(bluebubbles): prevent message routing to group chats when targeting phone numbers When sending a message to a phone number like +12622102921, the resolveChatGuidForTarget function was finding and returning a GROUP CHAT containing that phone number instead of a direct DM chat. The bug was in the participantMatch fallback logic which matched ANY chat containing the phone number as a participant, including groups. This fix adds a check to ensure participantMatch only considers DM chats (identified by ';-;' separator in the chat GUID). Group chats (identified by ';+;' separator) are now explicitly excluded from handle-based matching. If a phone number only exists in a group chat (no direct DM exists), the function now correctly returns null, which causes the send to fail with a clear error rather than accidentally messaging a group. Added test case to verify this behavior. * feat(bluebubbles): auto-create new DM chats when sending to unknown phone numbers When sending to a phone number that doesn't have an existing chat, instead of failing with 'chatGuid not found', now automatically creates a new chat using the /api/v1/chat/new endpoint. - Added createNewChatWithMessage() helper function - When resolveChatGuidForTarget returns null for a handle target, uses the new chat endpoint with addresses array and message - Includes helpful error message if Private API isn't enabled - Only applies to handle targets (phone numbers), not group chats * fix(bluebubbles): hide internal routing metadata in cross-context markers When sending cross-context messages via BlueBubbles, the origin marker was exposing internal chat_guid routing info like '[from bluebubbles:chat_guid:any;-;+19257864429]'. This adds a formatTargetDisplay() function to the BlueBubbles plugin that: - Extracts phone numbers from chat_guid formats (iMessage;-;+1234567890 -> +1234567890) - Normalizes handles for clean display - Avoids returning raw chat_guid formats containing internal routing metadata Now cross-context markers show clean identifiers like '[from +19257864429]' instead of exposing internal routing details to recipients. * fix: prevent cross-context decoration on direct message tool sends Two fixes: 1. Cross-context decoration (e.g., '[from +19257864429]' prefix) was being added to ALL messages sent to a different target, even when the agent was just composing a new message via the message tool. This decoration should only be applied when forwarding/relaying messages between chats. Fix: Added skipCrossContextDecoration flag to ChannelThreadingToolContext. The message tool now sets this flag to true, so direct sends don't get decorated. The buildCrossContextDecoration function checks this flag and returns null when set. 2. Aborted requests were still completing because the abort signal wasn't being passed through the message tool execution chain. Fix: Added abortSignal propagation from message tool → runMessageAction → executeSendAction → sendMessage → deliverOutboundPayloads. Added abort checks at key points in the chain to fail fast when aborted. Files changed: - src/channels/plugins/types.core.ts: Added skipCrossContextDecoration field - src/infra/outbound/outbound-policy.ts: Check skip flag before decorating - src/agents/tools/message-tool.ts: Set skip flag, accept and pass abort signal - src/infra/outbound/message-action-runner.ts: Pass abort signal through - src/infra/outbound/outbound-send-service.ts: Check and pass abort signal - src/infra/outbound/message.ts: Pass abort signal to delivery * fix(bluebubbles): preserve friendly display names in formatTargetDisplay
2026-01-25 02:03:08 -08:00
try {
const parsed = parseBlueBubblesTarget(trimmed);
if (parsed.kind === "chat_guid") {
const handle = extractHandleFromChatGuid(parsed.chatGuid);
2026-01-31 22:13:48 +09:00
if (handle) {
return handle;
}
fix(bluebubbles): route phone-number targets to direct chats; prevent internal IDs leaking in cross-context prefix (#1751) * fix(bluebubbles): prefer DM resolution + hide routing markers * fix(bluebubbles): prevent message routing to group chats when targeting phone numbers When sending a message to a phone number like +12622102921, the resolveChatGuidForTarget function was finding and returning a GROUP CHAT containing that phone number instead of a direct DM chat. The bug was in the participantMatch fallback logic which matched ANY chat containing the phone number as a participant, including groups. This fix adds a check to ensure participantMatch only considers DM chats (identified by ';-;' separator in the chat GUID). Group chats (identified by ';+;' separator) are now explicitly excluded from handle-based matching. If a phone number only exists in a group chat (no direct DM exists), the function now correctly returns null, which causes the send to fail with a clear error rather than accidentally messaging a group. Added test case to verify this behavior. * feat(bluebubbles): auto-create new DM chats when sending to unknown phone numbers When sending to a phone number that doesn't have an existing chat, instead of failing with 'chatGuid not found', now automatically creates a new chat using the /api/v1/chat/new endpoint. - Added createNewChatWithMessage() helper function - When resolveChatGuidForTarget returns null for a handle target, uses the new chat endpoint with addresses array and message - Includes helpful error message if Private API isn't enabled - Only applies to handle targets (phone numbers), not group chats * fix(bluebubbles): hide internal routing metadata in cross-context markers When sending cross-context messages via BlueBubbles, the origin marker was exposing internal chat_guid routing info like '[from bluebubbles:chat_guid:any;-;+19257864429]'. This adds a formatTargetDisplay() function to the BlueBubbles plugin that: - Extracts phone numbers from chat_guid formats (iMessage;-;+1234567890 -> +1234567890) - Normalizes handles for clean display - Avoids returning raw chat_guid formats containing internal routing metadata Now cross-context markers show clean identifiers like '[from +19257864429]' instead of exposing internal routing details to recipients. * fix: prevent cross-context decoration on direct message tool sends Two fixes: 1. Cross-context decoration (e.g., '[from +19257864429]' prefix) was being added to ALL messages sent to a different target, even when the agent was just composing a new message via the message tool. This decoration should only be applied when forwarding/relaying messages between chats. Fix: Added skipCrossContextDecoration flag to ChannelThreadingToolContext. The message tool now sets this flag to true, so direct sends don't get decorated. The buildCrossContextDecoration function checks this flag and returns null when set. 2. Aborted requests were still completing because the abort signal wasn't being passed through the message tool execution chain. Fix: Added abortSignal propagation from message tool → runMessageAction → executeSendAction → sendMessage → deliverOutboundPayloads. Added abort checks at key points in the chain to fail fast when aborted. Files changed: - src/channels/plugins/types.core.ts: Added skipCrossContextDecoration field - src/infra/outbound/outbound-policy.ts: Check skip flag before decorating - src/agents/tools/message-tool.ts: Set skip flag, accept and pass abort signal - src/infra/outbound/message-action-runner.ts: Pass abort signal through - src/infra/outbound/outbound-send-service.ts: Check and pass abort signal - src/infra/outbound/message.ts: Pass abort signal to delivery * fix(bluebubbles): preserve friendly display names in formatTargetDisplay
2026-01-25 02:03:08 -08:00
}
if (parsed.kind === "handle") {
return normalizeBlueBubblesHandle(parsed.to);
}
} catch {
// Fall through
}
// Strip common prefixes and try raw extraction
const stripped = trimmed
.replace(/^bluebubbles:/i, "")
.replace(/^chat_guid:/i, "")
.replace(/^chat_id:/i, "")
.replace(/^chat_identifier:/i, "");
const handle = extractHandleFromChatGuid(stripped);
2026-01-31 22:13:48 +09:00
if (handle) {
return handle;
}
fix(bluebubbles): route phone-number targets to direct chats; prevent internal IDs leaking in cross-context prefix (#1751) * fix(bluebubbles): prefer DM resolution + hide routing markers * fix(bluebubbles): prevent message routing to group chats when targeting phone numbers When sending a message to a phone number like +12622102921, the resolveChatGuidForTarget function was finding and returning a GROUP CHAT containing that phone number instead of a direct DM chat. The bug was in the participantMatch fallback logic which matched ANY chat containing the phone number as a participant, including groups. This fix adds a check to ensure participantMatch only considers DM chats (identified by ';-;' separator in the chat GUID). Group chats (identified by ';+;' separator) are now explicitly excluded from handle-based matching. If a phone number only exists in a group chat (no direct DM exists), the function now correctly returns null, which causes the send to fail with a clear error rather than accidentally messaging a group. Added test case to verify this behavior. * feat(bluebubbles): auto-create new DM chats when sending to unknown phone numbers When sending to a phone number that doesn't have an existing chat, instead of failing with 'chatGuid not found', now automatically creates a new chat using the /api/v1/chat/new endpoint. - Added createNewChatWithMessage() helper function - When resolveChatGuidForTarget returns null for a handle target, uses the new chat endpoint with addresses array and message - Includes helpful error message if Private API isn't enabled - Only applies to handle targets (phone numbers), not group chats * fix(bluebubbles): hide internal routing metadata in cross-context markers When sending cross-context messages via BlueBubbles, the origin marker was exposing internal chat_guid routing info like '[from bluebubbles:chat_guid:any;-;+19257864429]'. This adds a formatTargetDisplay() function to the BlueBubbles plugin that: - Extracts phone numbers from chat_guid formats (iMessage;-;+1234567890 -> +1234567890) - Normalizes handles for clean display - Avoids returning raw chat_guid formats containing internal routing metadata Now cross-context markers show clean identifiers like '[from +19257864429]' instead of exposing internal routing details to recipients. * fix: prevent cross-context decoration on direct message tool sends Two fixes: 1. Cross-context decoration (e.g., '[from +19257864429]' prefix) was being added to ALL messages sent to a different target, even when the agent was just composing a new message via the message tool. This decoration should only be applied when forwarding/relaying messages between chats. Fix: Added skipCrossContextDecoration flag to ChannelThreadingToolContext. The message tool now sets this flag to true, so direct sends don't get decorated. The buildCrossContextDecoration function checks this flag and returns null when set. 2. Aborted requests were still completing because the abort signal wasn't being passed through the message tool execution chain. Fix: Added abortSignal propagation from message tool → runMessageAction → executeSendAction → sendMessage → deliverOutboundPayloads. Added abort checks at key points in the chain to fail fast when aborted. Files changed: - src/channels/plugins/types.core.ts: Added skipCrossContextDecoration field - src/infra/outbound/outbound-policy.ts: Check skip flag before decorating - src/agents/tools/message-tool.ts: Set skip flag, accept and pass abort signal - src/infra/outbound/message-action-runner.ts: Pass abort signal through - src/infra/outbound/outbound-send-service.ts: Check and pass abort signal - src/infra/outbound/message.ts: Pass abort signal to delivery * fix(bluebubbles): preserve friendly display names in formatTargetDisplay
2026-01-25 02:03:08 -08:00
// Don't return raw chat_guid formats - they contain internal routing info
2026-01-31 22:13:48 +09:00
if (stripped.includes(";-;") || stripped.includes(";+;")) {
return null;
}
fix(bluebubbles): route phone-number targets to direct chats; prevent internal IDs leaking in cross-context prefix (#1751) * fix(bluebubbles): prefer DM resolution + hide routing markers * fix(bluebubbles): prevent message routing to group chats when targeting phone numbers When sending a message to a phone number like +12622102921, the resolveChatGuidForTarget function was finding and returning a GROUP CHAT containing that phone number instead of a direct DM chat. The bug was in the participantMatch fallback logic which matched ANY chat containing the phone number as a participant, including groups. This fix adds a check to ensure participantMatch only considers DM chats (identified by ';-;' separator in the chat GUID). Group chats (identified by ';+;' separator) are now explicitly excluded from handle-based matching. If a phone number only exists in a group chat (no direct DM exists), the function now correctly returns null, which causes the send to fail with a clear error rather than accidentally messaging a group. Added test case to verify this behavior. * feat(bluebubbles): auto-create new DM chats when sending to unknown phone numbers When sending to a phone number that doesn't have an existing chat, instead of failing with 'chatGuid not found', now automatically creates a new chat using the /api/v1/chat/new endpoint. - Added createNewChatWithMessage() helper function - When resolveChatGuidForTarget returns null for a handle target, uses the new chat endpoint with addresses array and message - Includes helpful error message if Private API isn't enabled - Only applies to handle targets (phone numbers), not group chats * fix(bluebubbles): hide internal routing metadata in cross-context markers When sending cross-context messages via BlueBubbles, the origin marker was exposing internal chat_guid routing info like '[from bluebubbles:chat_guid:any;-;+19257864429]'. This adds a formatTargetDisplay() function to the BlueBubbles plugin that: - Extracts phone numbers from chat_guid formats (iMessage;-;+1234567890 -> +1234567890) - Normalizes handles for clean display - Avoids returning raw chat_guid formats containing internal routing metadata Now cross-context markers show clean identifiers like '[from +19257864429]' instead of exposing internal routing details to recipients. * fix: prevent cross-context decoration on direct message tool sends Two fixes: 1. Cross-context decoration (e.g., '[from +19257864429]' prefix) was being added to ALL messages sent to a different target, even when the agent was just composing a new message via the message tool. This decoration should only be applied when forwarding/relaying messages between chats. Fix: Added skipCrossContextDecoration flag to ChannelThreadingToolContext. The message tool now sets this flag to true, so direct sends don't get decorated. The buildCrossContextDecoration function checks this flag and returns null when set. 2. Aborted requests were still completing because the abort signal wasn't being passed through the message tool execution chain. Fix: Added abortSignal propagation from message tool → runMessageAction → executeSendAction → sendMessage → deliverOutboundPayloads. Added abort checks at key points in the chain to fail fast when aborted. Files changed: - src/channels/plugins/types.core.ts: Added skipCrossContextDecoration field - src/infra/outbound/outbound-policy.ts: Check skip flag before decorating - src/agents/tools/message-tool.ts: Set skip flag, accept and pass abort signal - src/infra/outbound/message-action-runner.ts: Pass abort signal through - src/infra/outbound/outbound-send-service.ts: Check and pass abort signal - src/infra/outbound/message.ts: Pass abort signal to delivery * fix(bluebubbles): preserve friendly display names in formatTargetDisplay
2026-01-25 02:03:08 -08:00
return stripped;
};
// Try to get a clean display from the display parameter first
const trimmedDisplay = display?.trim();
if (trimmedDisplay) {
if (!shouldParseDisplay(trimmedDisplay)) {
return trimmedDisplay;
}
const cleanDisplay = extractCleanDisplay(trimmedDisplay);
2026-01-31 22:13:48 +09:00
if (cleanDisplay) {
return cleanDisplay;
}
fix(bluebubbles): route phone-number targets to direct chats; prevent internal IDs leaking in cross-context prefix (#1751) * fix(bluebubbles): prefer DM resolution + hide routing markers * fix(bluebubbles): prevent message routing to group chats when targeting phone numbers When sending a message to a phone number like +12622102921, the resolveChatGuidForTarget function was finding and returning a GROUP CHAT containing that phone number instead of a direct DM chat. The bug was in the participantMatch fallback logic which matched ANY chat containing the phone number as a participant, including groups. This fix adds a check to ensure participantMatch only considers DM chats (identified by ';-;' separator in the chat GUID). Group chats (identified by ';+;' separator) are now explicitly excluded from handle-based matching. If a phone number only exists in a group chat (no direct DM exists), the function now correctly returns null, which causes the send to fail with a clear error rather than accidentally messaging a group. Added test case to verify this behavior. * feat(bluebubbles): auto-create new DM chats when sending to unknown phone numbers When sending to a phone number that doesn't have an existing chat, instead of failing with 'chatGuid not found', now automatically creates a new chat using the /api/v1/chat/new endpoint. - Added createNewChatWithMessage() helper function - When resolveChatGuidForTarget returns null for a handle target, uses the new chat endpoint with addresses array and message - Includes helpful error message if Private API isn't enabled - Only applies to handle targets (phone numbers), not group chats * fix(bluebubbles): hide internal routing metadata in cross-context markers When sending cross-context messages via BlueBubbles, the origin marker was exposing internal chat_guid routing info like '[from bluebubbles:chat_guid:any;-;+19257864429]'. This adds a formatTargetDisplay() function to the BlueBubbles plugin that: - Extracts phone numbers from chat_guid formats (iMessage;-;+1234567890 -> +1234567890) - Normalizes handles for clean display - Avoids returning raw chat_guid formats containing internal routing metadata Now cross-context markers show clean identifiers like '[from +19257864429]' instead of exposing internal routing details to recipients. * fix: prevent cross-context decoration on direct message tool sends Two fixes: 1. Cross-context decoration (e.g., '[from +19257864429]' prefix) was being added to ALL messages sent to a different target, even when the agent was just composing a new message via the message tool. This decoration should only be applied when forwarding/relaying messages between chats. Fix: Added skipCrossContextDecoration flag to ChannelThreadingToolContext. The message tool now sets this flag to true, so direct sends don't get decorated. The buildCrossContextDecoration function checks this flag and returns null when set. 2. Aborted requests were still completing because the abort signal wasn't being passed through the message tool execution chain. Fix: Added abortSignal propagation from message tool → runMessageAction → executeSendAction → sendMessage → deliverOutboundPayloads. Added abort checks at key points in the chain to fail fast when aborted. Files changed: - src/channels/plugins/types.core.ts: Added skipCrossContextDecoration field - src/infra/outbound/outbound-policy.ts: Check skip flag before decorating - src/agents/tools/message-tool.ts: Set skip flag, accept and pass abort signal - src/infra/outbound/message-action-runner.ts: Pass abort signal through - src/infra/outbound/outbound-send-service.ts: Check and pass abort signal - src/infra/outbound/message.ts: Pass abort signal to delivery * fix(bluebubbles): preserve friendly display names in formatTargetDisplay
2026-01-25 02:03:08 -08:00
}
// Fall back to extracting from target
const cleanTarget = extractCleanDisplay(target);
2026-01-31 22:13:48 +09:00
if (cleanTarget) {
return cleanTarget;
}
fix(bluebubbles): route phone-number targets to direct chats; prevent internal IDs leaking in cross-context prefix (#1751) * fix(bluebubbles): prefer DM resolution + hide routing markers * fix(bluebubbles): prevent message routing to group chats when targeting phone numbers When sending a message to a phone number like +12622102921, the resolveChatGuidForTarget function was finding and returning a GROUP CHAT containing that phone number instead of a direct DM chat. The bug was in the participantMatch fallback logic which matched ANY chat containing the phone number as a participant, including groups. This fix adds a check to ensure participantMatch only considers DM chats (identified by ';-;' separator in the chat GUID). Group chats (identified by ';+;' separator) are now explicitly excluded from handle-based matching. If a phone number only exists in a group chat (no direct DM exists), the function now correctly returns null, which causes the send to fail with a clear error rather than accidentally messaging a group. Added test case to verify this behavior. * feat(bluebubbles): auto-create new DM chats when sending to unknown phone numbers When sending to a phone number that doesn't have an existing chat, instead of failing with 'chatGuid not found', now automatically creates a new chat using the /api/v1/chat/new endpoint. - Added createNewChatWithMessage() helper function - When resolveChatGuidForTarget returns null for a handle target, uses the new chat endpoint with addresses array and message - Includes helpful error message if Private API isn't enabled - Only applies to handle targets (phone numbers), not group chats * fix(bluebubbles): hide internal routing metadata in cross-context markers When sending cross-context messages via BlueBubbles, the origin marker was exposing internal chat_guid routing info like '[from bluebubbles:chat_guid:any;-;+19257864429]'. This adds a formatTargetDisplay() function to the BlueBubbles plugin that: - Extracts phone numbers from chat_guid formats (iMessage;-;+1234567890 -> +1234567890) - Normalizes handles for clean display - Avoids returning raw chat_guid formats containing internal routing metadata Now cross-context markers show clean identifiers like '[from +19257864429]' instead of exposing internal routing details to recipients. * fix: prevent cross-context decoration on direct message tool sends Two fixes: 1. Cross-context decoration (e.g., '[from +19257864429]' prefix) was being added to ALL messages sent to a different target, even when the agent was just composing a new message via the message tool. This decoration should only be applied when forwarding/relaying messages between chats. Fix: Added skipCrossContextDecoration flag to ChannelThreadingToolContext. The message tool now sets this flag to true, so direct sends don't get decorated. The buildCrossContextDecoration function checks this flag and returns null when set. 2. Aborted requests were still completing because the abort signal wasn't being passed through the message tool execution chain. Fix: Added abortSignal propagation from message tool → runMessageAction → executeSendAction → sendMessage → deliverOutboundPayloads. Added abort checks at key points in the chain to fail fast when aborted. Files changed: - src/channels/plugins/types.core.ts: Added skipCrossContextDecoration field - src/infra/outbound/outbound-policy.ts: Check skip flag before decorating - src/agents/tools/message-tool.ts: Set skip flag, accept and pass abort signal - src/infra/outbound/message-action-runner.ts: Pass abort signal through - src/infra/outbound/outbound-send-service.ts: Check and pass abort signal - src/infra/outbound/message.ts: Pass abort signal to delivery * fix(bluebubbles): preserve friendly display names in formatTargetDisplay
2026-01-25 02:03:08 -08:00
// Last resort: return display or target as-is
return display?.trim() || target?.trim() || "";
},
},
2026-01-18 03:17:30 +00:00
setup: {
resolveAccountId: ({ accountId }) => normalizeAccountId(accountId),
applyAccountName: ({ cfg, accountId, name }) =>
applyAccountNameToChannelSection({
2026-01-31 22:13:48 +09:00
cfg: cfg,
2026-01-18 03:17:30 +00:00
channelKey: "bluebubbles",
accountId,
name,
}),
validateInput: ({ input }) => {
if (!input.httpUrl && !input.password) {
return "BlueBubbles requires --http-url and --password.";
}
2026-01-31 22:13:48 +09:00
if (!input.httpUrl) {
return "BlueBubbles requires --http-url.";
}
if (!input.password) {
return "BlueBubbles requires --password.";
}
2026-01-18 03:17:30 +00:00
return null;
},
applyAccountConfig: ({ cfg, accountId, input }) => {
const namedConfig = applyAccountNameToChannelSection({
2026-01-31 22:13:48 +09:00
cfg: cfg,
2026-01-18 03:17:30 +00:00
channelKey: "bluebubbles",
accountId,
name: input.name,
});
const next =
accountId !== DEFAULT_ACCOUNT_ID
? migrateBaseNameToDefaultAccount({
cfg: namedConfig,
channelKey: "bluebubbles",
})
: namedConfig;
if (accountId === DEFAULT_ACCOUNT_ID) {
return {
...next,
channels: {
...next.channels,
bluebubbles: {
...next.channels?.bluebubbles,
enabled: true,
...(input.httpUrl ? { serverUrl: input.httpUrl } : {}),
...(input.password ? { password: input.password } : {}),
2026-01-19 18:06:30 -08:00
...(input.webhookPath ? { webhookPath: input.webhookPath } : {}),
2026-01-18 03:17:30 +00:00
},
},
2026-01-30 03:15:10 +01:00
} as OpenClawConfig;
2026-01-18 03:17:30 +00:00
}
return {
...next,
channels: {
...next.channels,
bluebubbles: {
...next.channels?.bluebubbles,
enabled: true,
accounts: {
2026-01-31 22:13:48 +09:00
...next.channels?.bluebubbles?.accounts,
2026-01-18 03:17:30 +00:00
[accountId]: {
2026-01-31 22:13:48 +09:00
...next.channels?.bluebubbles?.accounts?.[accountId],
2026-01-18 03:17:30 +00:00
enabled: true,
...(input.httpUrl ? { serverUrl: input.httpUrl } : {}),
...(input.password ? { password: input.password } : {}),
2026-01-19 18:06:30 -08:00
...(input.webhookPath ? { webhookPath: input.webhookPath } : {}),
2026-01-18 03:17:30 +00:00
},
},
},
},
2026-01-30 03:15:10 +01:00
} as OpenClawConfig;
2026-01-18 03:17:30 +00:00
},
},
pairing: {
idLabel: "bluebubblesSenderId",
normalizeAllowEntry: (entry) => normalizeBlueBubblesHandle(entry.replace(/^bluebubbles:/i, "")),
notifyApproval: async ({ cfg, id }) => {
await sendMessageBlueBubbles(id, PAIRING_APPROVED_MESSAGE, {
2026-01-31 22:13:48 +09:00
cfg: cfg,
2026-01-18 03:17:30 +00:00
});
},
},
outbound: {
deliveryMode: "direct",
textChunkLimit: 4000,
resolveTarget: ({ to }) => {
const trimmed = to?.trim();
if (!trimmed) {
return {
ok: false,
error: new Error("Delivering to BlueBubbles requires --to <handle|chat_guid:GUID>"),
};
}
return { ok: true, to: trimmed };
},
sendText: async ({ cfg, to, text, accountId, replyToId }) => {
const rawReplyToId = typeof replyToId === "string" ? replyToId.trim() : "";
// Resolve short ID (e.g., "5") to full UUID
const replyToMessageGuid = rawReplyToId
? resolveBlueBubblesMessageId(rawReplyToId, { requireKnownShortId: true })
: "";
const result = await sendMessageBlueBubbles(to, text, {
2026-01-31 22:13:48 +09:00
cfg: cfg,
2026-01-18 03:17:30 +00:00
accountId: accountId ?? undefined,
replyToMessageGuid: replyToMessageGuid || undefined,
2026-01-18 03:17:30 +00:00
});
return { channel: "bluebubbles", ...result };
},
2026-01-19 18:39:56 -08:00
sendMedia: async (ctx) => {
const { cfg, to, text, mediaUrl, accountId, replyToId } = ctx;
2026-01-19 18:39:56 -08:00
const { mediaPath, mediaBuffer, contentType, filename, caption } = ctx as {
mediaPath?: string;
mediaBuffer?: Uint8Array;
contentType?: string;
filename?: string;
caption?: string;
};
const resolvedCaption = caption ?? text;
const result = await sendBlueBubblesMedia({
2026-01-31 22:13:48 +09:00
cfg: cfg,
to,
mediaUrl,
mediaPath,
mediaBuffer,
contentType,
filename,
2026-01-19 18:39:56 -08:00
caption: resolvedCaption ?? undefined,
replyToId: replyToId ?? null,
accountId: accountId ?? undefined,
});
return { channel: "bluebubbles", ...result };
2026-01-18 03:17:30 +00:00
},
},
status: {
defaultRuntime: {
accountId: DEFAULT_ACCOUNT_ID,
running: false,
lastStartAt: null,
lastStopAt: null,
lastError: null,
},
2026-01-19 18:50:22 -08:00
collectStatusIssues: collectBlueBubblesStatusIssues,
2026-01-18 03:17:30 +00:00
buildChannelSummary: ({ snapshot }) => ({
configured: snapshot.configured ?? false,
baseUrl: snapshot.baseUrl ?? null,
running: snapshot.running ?? false,
lastStartAt: snapshot.lastStartAt ?? null,
lastStopAt: snapshot.lastStopAt ?? null,
lastError: snapshot.lastError ?? null,
probe: snapshot.probe,
lastProbeAt: snapshot.lastProbeAt ?? null,
}),
probeAccount: async ({ account, timeoutMs }) =>
probeBlueBubbles({
baseUrl: account.baseUrl,
password: account.config.password ?? null,
timeoutMs,
}),
buildAccountSnapshot: ({ account, runtime, probe }) => {
const running = runtime?.running ?? false;
const probeOk = (probe as BlueBubblesProbe | undefined)?.ok;
return {
accountId: account.accountId,
name: account.name,
enabled: account.enabled,
configured: account.configured,
baseUrl: account.baseUrl,
running,
connected: probeOk ?? running,
lastStartAt: runtime?.lastStartAt ?? null,
lastStopAt: runtime?.lastStopAt ?? null,
lastError: runtime?.lastError ?? null,
probe,
lastInboundAt: runtime?.lastInboundAt ?? null,
lastOutboundAt: runtime?.lastOutboundAt ?? null,
};
},
2026-01-18 03:17:30 +00:00
},
gateway: {
startAccount: async (ctx) => {
const account = ctx.account;
const webhookPath = resolveWebhookPathFromConfig(account.config);
ctx.setStatus({
accountId: account.accountId,
baseUrl: account.baseUrl,
});
ctx.log?.info(`[${account.accountId}] starting provider (webhook=${webhookPath})`);
return monitorBlueBubblesProvider({
account,
2026-01-31 22:13:48 +09:00
config: ctx.cfg,
2026-01-18 03:17:30 +00:00
runtime: ctx.runtime,
abortSignal: ctx.abortSignal,
statusSink: (patch) => ctx.setStatus({ accountId: ctx.accountId, ...patch }),
webhookPath,
});
},
},
};