Approval decisions are not de-duplicated, so an approval-gated tool can execute twice

[lullu57]

Summary

When resuming a paused conversation, the SDK iterates approveToolCalls and rejectToolCalls as plain lists with no de-duplication or intersection check. A call id listed twice in approveToolCalls executes the matching tool twice. A call id present in both arrays executes the tool and records a rejection for the same id.

This only matters for applications that use the human-in-the-loop approval feature and pass decision arrays they don't validate (for example, arrays built from end-user or client input). Apps that don't use approvals are unaffected.

Affected code

src/lib/model-result.ts (on main, d26f835), in processApprovalDecisions():

for (const callId of this.approvedToolCalls) {       // no dedup
  const toolCall = pendingCalls.find(tc => tc.id === callId);
  ...
  const result = await executeTool(tool, ...);       // runs once per duplicate
}
for (const callId of this.rejectedToolCalls) { ... }  // runs even if also approved
const processedIds = new Set([...this.approvedToolCalls, ...this.rejectedToolCalls]);

The Set is only used to filter the remaining pending list; it does not gate execution.

Impact

Approval-gated tools usually guard side effects (a payment, an outbound call, a record write). A duplicate id can double that side effect. An id in both arrays produces a contradictory record — the tool ran, yet the trail shows it was rejected.

How to reproduce / confirm

1. Resume a paused conversation with a pending tool call call_1.
2. Case A: pass approveToolCalls: ['call_1', 'call_1'] → the tool executes twice (two result entries).
3. Case B: pass approveToolCalls: ['call_1'] and rejectToolCalls: ['call_1'] → the tool executes and a rejection is also recorded.

Suggested fix

Validate decisions before executing: reject duplicate ids within each array and reject any id present in both arrays. Execute approvals and record rejections only from the validated, de-duplicated sets.

[trippyogi]

Suggested fix (not a PR — per CONTRIBUTING)

CONTRIBUTING.md says this repo doesn’t accept direct PRs, so I’m closing #631 and leaving the patch on a fork for maintainers to apply upstream.

Confirmed

On current main, processApprovalDecisions() iterates approveToolCalls / rejectToolCalls as plain arrays with no de-dup or intersection check:

• Duplicate id in approveToolCalls → tool executes twice
• Same id in both arrays → tool executes and a rejection is recorded

Proposed behavior

Treat approval decisions as a security boundary: validate-then-throw at ModelResult construction (same place as the existing “decisions require `state” guard), before any tool runs or state mutates.

Throw a clear Error when:

1. Duplicate id(s) within approveToolCalls
2. Duplicate id(s) within rejectToolCalls
3. Any id present in both arrays

Do not silent-Set dedup or first-wins — that hides caller bugs and, for approve∩reject, can still execute a tool the caller also intended to reject. Correct callers already pass unique disjoint ids and are unaffected.

Leave processApprovalDecisions() unchanged once the arrays are guaranteed distinct and disjoint. Unknown / already-processed ids can keep being silently skipped (idempotent re-resume).

Patch location

Branch: https://github.com/trippyogi/typescript-sdk/tree/fix/issue-518
Diff: trippyogi/typescript-sdk@main...fix/issue-518

Touches only hand-written files:

• src/lib/model-result.ts — validateApprovalDecisions() called from the constructor
• src/lib/async-params.ts — tsdoc note that ids must be distinct and disjoint
• tests/unit/issue-518-approval-dedup.test.ts — offline unit coverage (throw + happy path)

Happy to adjust (e.g. softer warn+dedup) if you’d rather that upstream.