Resolved card drops command/cwd from the pending card

The pending card shows the command and working directory (built in buildPendingContent), but finalizeResolved ignores _request and omits them from the resolved card. Because Feishu updates the card in-place (the pending card is replaced), the approver loses visibility into which command was approved/denied once the card flips state.

For exec approvals, the data is readily available in _request:

private async finalizeResolved(
  request: ApprovalRequest,
  resolved: ApprovalResolved,
  messages: PendingMessage[],
): Promise<void> {
  const execRequest = resolved.id && (request as ExecApprovalRequest).request
    ? (request as ExecApprovalRequest)
    : null;
  const commandDisplay = execRequest
    ? resolveExecApprovalCommandDisplay(execRequest.request)
    : null;
  await Promise.allSettled(
    messages.map(async (message) => {
      try {
        const resolvedCard = createExecApprovalResolvedCard({
          approvalId: resolved.id,
          decision: resolved.decision,
          resolvedBy: resolved.resolvedBy ?? undefined,
          command: commandDisplay?.commandText,
          cwd: execRequest?.request.cwd ?? undefined,
        });
        ...

This is a comment left during a code review.
Path: extensions/feishu/src/exec-approvals-handler.ts
Line: 138-163

Comment:
**Resolved card drops command/cwd from the pending card**

The pending card shows the command and working directory (built in `buildPendingContent`), but `finalizeResolved` ignores `_request` and omits them from the resolved card. Because Feishu updates the card in-place (the pending card is replaced), the approver loses visibility into which command was approved/denied once the card flips state.

For exec approvals, the data is readily available in `_request`:

```ts
private async finalizeResolved(
  request: ApprovalRequest,
  resolved: ApprovalResolved,
  messages: PendingMessage[],
): Promise<void> {
  const execRequest = resolved.id && (request as ExecApprovalRequest).request
    ? (request as ExecApprovalRequest)
    : null;
  const commandDisplay = execRequest
    ? resolveExecApprovalCommandDisplay(execRequest.request)
    : null;
  await Promise.allSettled(
    messages.map(async (message) => {
      try {
        const resolvedCard = createExecApprovalResolvedCard({
          approvalId: resolved.id,
          decision: resolved.decision,
          resolvedBy: resolved.resolvedBy ?? undefined,
          command: commandDisplay?.commandText,
          cwd: execRequest?.request.cwd ?? undefined,
        });
        ...
```

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

Fixed in d61c190. finalizeResolved now extracts command/cwd from the request and passes them to createExecApprovalResolvedCard, so the resolved card retains full context about what was approved/denied.

Preserve legacy Feishu /approve authorization path

Adding approvalCapability here causes Feishu approval auth to be taken from feishuApprovalCapability (exec-approver list) instead of the existing auth: feishuApprovalAuth allowlist path, because channel capability auth takes precedence over legacy auth wiring. In setups that have existing Feishu approvers via channels.feishu.allowFrom but do not configure channels.feishu.execApprovals.approvers (the new feature is supposed to be opt-in), /approve now resolves to unauthorized for both exec and plugin approvals, so pending approvals can be sent but cannot be resolved.

Useful? React with 👍 / 👎.

Fixed in d61c190. getFeishuExecApprovalApprovers now falls back to allowFrom (matching the Telegram pattern), so existing setups that rely on channels.feishu.allowFrom for approval authorization continue to work without requiring explicit execApprovals.approvers config.

Gate local prompt suppression on approval request filters

shouldSuppressLocalFeishuExecApprovalPrompt suppresses any exec-approval payload whenever the Feishu client is enabled, but it does not check agentFilter/sessionFilter. In the same module, shouldHandleFeishuExecApprovalRequest does enforce those filters, so filtered requests can be skipped by the native handler while their fallback text prompt is still suppressed, leaving no Feishu approval prompt for those requests. Suppression should be aligned with the same request-level filter predicate used for handling.

Useful? React with 👍 / 👎.

This matches Telegram's behavior — shouldSuppressLocalTelegramExecApprovalPrompt also delegates to profile.shouldSuppressLocalPrompt without additional agentFilter/sessionFilter checks. If this needs to be tightened, it should be done at the createChannelExecApprovalProfile framework level to keep all channels consistent.

Reject unsupported on_ approver IDs or authorize them correctly

This normalizer now accepts on_ IDs as valid approvers, but approval authorization compares against Feishu open_id values (for example card actions pass event.operator.open_id), so on_... entries cannot actually pass approver checks at runtime. That makes config silently accept approvers that can never approve requests. Either restrict accepted IDs to the identifier type used by auth checks or add consistent union-id matching across authorization paths.

Useful? React with 👍 / 👎.

Fixed in 9a6891a. Approver normalizer now only accepts ou_ (open_id) prefix. on_ (union_id) is rejected since card action callbacks use event.operator.open_id which is always ou_-prefixed.

Normalize Feishu approver IDs before prefix checks

getFeishuExecApprovalApprovers now uses normalizeFeishuDirectApproverId for both explicit approvers and allowFrom, but that normalizer only accepts raw lowercase ou_... strings. Existing valid Feishu allowlist forms such as user:ou_xxx, feishu:user:ou_xxx, or uppercase variants are filtered out, which can empty the approver set and make /approve unauthorized after approvalCapability takes precedence over legacy auth. This is a regression for configurations that previously relied on the broader Feishu ID normalization behavior.

Useful? React with 👍 / 👎.

Fixed in cde6083. normalizeFeishuDirectApproverId now uses parseFeishuDirectConversationId to handle prefixed forms (user:ou_xxx, feishu:user:ou_xxx, etc.) before validating the ou_ prefix.

Restrict ambiguous non-Feishu requests to one account

The account-matching predicate treats boundAccountId === null as a match for every Feishu account, and for non-Feishu turn sources this path is guaranteed because resolveApprovalRequestAccountId is called with channel: "feishu". In multi-account setups, a single non-Feishu approval request can therefore be handled by multiple Feishu handlers, causing duplicate prompts and leaking command details across accounts. The matcher should gate this ambiguous case (for example, only allow when there is exactly one eligible Feishu account), as done in other channel implementations.

Useful? React with 👍 / 👎.

Fixed in cde6083. Added countFeishuExecApprovalEligibleAccounts and matchesFeishuRequestAccount — for non-Feishu turn sources with no bound account, the handler only proceeds when there is exactly one eligible Feishu account, matching Telegram's pattern.

Wire Feishu routing guards into approval capability

This capability only spreads feishuApprovalCapability, so the new forwarding safeguards in exec-approval-forwarding.ts are never applied. In practice, requests that bypass native suppression (for example, approvals originating from a non-Feishu turn source with channels.feishu.execApprovals.target: "dm") can still be forwarded by the generic exec forwarder to Feishu channel targets, which leaks command/cwd details into chats that the Feishu target mode was meant to exclude. The channel capability needs to register the Feishu-specific pending payload/suppression hooks instead of relying solely on the native adapter.

Useful? React with 👍 / 👎.

This is already handled by the framework. createApproverRestrictedNativeApprovalCapability internally wires up shouldSuppressForwardingFallback (see src/plugin-sdk/approval-delivery-helpers.ts:112), so feishuApprovalCapability already includes forwarding suppression. Telegram doesn't register it separately either — it's built into the capability.

Normalize Feishu target IDs before auth matching

Recipient authorization compares target.to by stripping only the user: prefix, so equivalent Feishu ID forms like dm:ou_xxx, open_id:ou_xxx, or provider-prefixed forms are treated as different users. If teams configure approvals.exec.targets with those accepted Feishu address forms, the intended recipient fails isTargetRecipient and /approve is rejected unless they are also in the approver list. This matcher should normalize with the same Feishu target parser used elsewhere.

Useful? React with 👍 / 👎.

Fixed in 7692637. isFeishuExecApprovalTargetRecipient now uses parseFeishuDirectConversationId to normalize all Feishu address forms (dm:ou_xxx, open_id:ou_xxx, feishu:user:ou_xxx, bare ou_xxx) consistently with the approver normalization path.

Validate parsed Feishu approver IDs before returning them

normalizeFeishuDirectApproverId returns any value produced by parseFeishuDirectConversationId without checking that it is an ou_ open_id, so entries like user:foo or user:OU_123 are treated as configured approvers. Those values increase approver count and enable the native exec-approval client, but they can never match card callback event.operator.open_id, which leaves approvals effectively unresolvable in production configs that use prefixed IDs. Fresh evidence is that parseFeishuDirectConversationId accepts any user: suffix, so this early return bypasses the intended ou_ validation.

Useful? React with 👍 / 👎.