This is a comment left during a code review.
Path: extensions/telegram/src/exec-approvals.ts
Line: 49-61

Comment:
**Missing `fallbackAgentIdFromSessionKey` in Telegram profile**

The old `matchesFilters` function in `exec-approvals-handler.ts` explicitly passed `fallbackAgentIdFromSessionKey: true` to `matchesApprovalRequestFilters`. The new `telegramExecApprovalProfile` does not set this flag, so it silently defaults to `false`.

This is a behavioral regression: when a Telegram approval config uses `agentFilter` and the request's `agentId` is absent (relying on extraction from the session key), filter matching will now fail where it previously succeeded.

```suggestion
const telegramExecApprovalProfile = createChannelExecApprovalProfile({
  resolveConfig: resolveTelegramExecApprovalConfig,
  resolveApprovers: getTelegramExecApprovalApprovers,
  isTargetRecipient: isTelegramExecApprovalTargetRecipient,
  matchesRequestAccount: ({ cfg, accountId, request }) => {
    const boundAccountId = resolveApprovalRequestAccountId({
      cfg,
      request,
      channel:
        request.request.turnSourceChannel?.trim().toLowerCase() === "telegram" ? null : "telegram",
    });
    return (
      !boundAccountId ||
      !accountId ||
      normalizeAccountId(boundAccountId) === normalizeAccountId(accountId)
    );
  },
  fallbackAgentIdFromSessionKey: true,
  requireClientEnabledForLocalPromptSuppression: false,
});
```

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

---

This is a comment left during a code review.
Path: extensions/discord/src/approval-native.ts
Line: 64-69

Comment:
**`shouldHandleDiscordApprovalRequest` returns `true` when config is absent**

When both `configOverride` and the account's `execApprovals` are `null`/`undefined`, `config` is falsy and the function returns `true`. This is surprising for a predicate named `should handle` — callers reasonably expect `false` when no approval config is present.

While the downstream delivery pipeline guards against actual delivery (via `hasApprovers` → `enabled: false` in `describeDeliveryCapabilities`), the semantics of this exported function are misleading and could cause confusion for future consumers.

Consider returning `false` here, since an absent config means approvals are not configured:

```suggestion
  if (!config) {
    return false;
  }
```

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