fix: deduplicate tool_use IDs and enable sanitization for Anthropic by marcelomar21 · Pull Request #4700 · openclaw/openclaw

marcelomar21 · 2026-01-30T14:54:05Z

Summary

Fixes Anthropic API rejection error: messages.X.content.Y: tool_use ids must be unique

This issue occurs when:

Session transcripts accumulate multiple assistant messages with the same tool_use ID (e.g., from retries or long conversations)
Tool IDs contain special characters (spaces, colons) that weren't being sanitized for Anthropic

Changes

Add deduplication logic in repairToolUseResultPairing() to detect and rename duplicate tool_use IDs in assistant messages (e.g., call_1 → call_1_2)
Update corresponding toolResult IDs to match the remapped tool_use IDs
Enable sanitizeToolCallIds for Anthropic provider (previously only Google/Mistral)
Add tests for deduplication scenarios

Test plan

Existing tests pass (session-transcript-repair.test.ts)
New tests added for duplicate ID scenarios
Verified fix resolves the error in production session with duplicate IDs

Greptile Overview

Greptile Summary

This PR strengthens transcript sanitization/repair for Anthropic-compatible requests by (1) enabling sanitizeToolCallIds for Anthropic in the transcript policy and (2) extending repairToolUseResultPairing() to deduplicate duplicate assistant tool_use IDs across a session and remap the corresponding toolResult IDs. Tests were updated/added to cover the new Anthropic sanitize flag and a basic duplicate-ID-across-messages scenario.

The changes fit into the existing transcript hygiene pipeline (sanitizeSessionHistory in src/agents/pi-embedded-runner/google.ts), where messages are first sanitized (including tool call IDs) and then repaired to ensure strict toolCall/toolResult ordering expected by providers like Anthropic.

Confidence Score: 3/5

This PR is close to safe to merge, but has a correctness edge case around duplicate IDs within a single assistant turn that could drop tool results.
The overall approach (deduplicate IDs + remap toolResult IDs, and enable sanitization for Anthropic) matches the reported provider constraint and is covered by new tests. However, the current remapping uses a Map keyed by the original ID, so duplicates within the same assistant message can collapse to one remapped ID and cause pushToolResult to treat later results as duplicates and drop them. That edge case could affect real transcripts if a retry duplicates blocks inside one message.
src/agents/session-transcript-repair.ts

_{(3/5) Reply to the agent's comments like "Can you suggest a fix for this @greptileai?" or ask follow-up questions!}

Context used:

Context from dashboard - CLAUDE.md (source)
Context from dashboard - AGENTS.md (source)

greptile-apps

_{1 file reviewed, 1 comment}

_{Edit Code Review Agent Settings | Greptile}

greptile-apps · 2026-02-03T02:25:49Z

src/agents/session-transcript-repair.ts

+    // Check for duplicate tool_use IDs and remap them if necessary
+    const idRemapping = new Map<string, string>();
+    let assistantNeedsRewrite = false;


[P0] Deduplication remapping can drop tool calls/results when an assistant contains duplicate IDs in the same message.

Because idRemapping is keyed by the original ID, multiple tool calls with the same call.id in a single assistant turn will all map to the same new ID (the last one wins). Then effectiveToolCalls ends up with repeated id values, and pushToolResult will drop the second result as a duplicate (since it tracks seenToolResultIds by toolCallId). This can silently lose tool results and/or synthesize a missing result for the second call.

Scenario: assistant has two tool calls both id: "call_1", followed by two toolResults with toolCallId: "call_1" and different content. After rewrite, both tool calls become call_1_2, and the second toolResult is dropped as a duplicate.

Consider disambiguating duplicate IDs within a single assistant message (e.g., track per-call occurrence index rather than mapping by ID), or reject/repair at extraction time.

Also appears in: src/agents/session-transcript-repair.test.ts lacks coverage for same-message duplicate IDs.

Prompt To Fix With AI

This is a comment left during a code review. Path: src/agents/session-transcript-repair.ts Line: 156:158 Comment: [P0] Deduplication remapping can drop tool calls/results when an assistant contains duplicate IDs in the *same* message. Because `idRemapping` is keyed by the original ID, multiple tool calls with the same `call.id` in a single assistant turn will all map to the same new ID (the last one wins). Then `effectiveToolCalls` ends up with repeated `id` values, and `pushToolResult` will drop the second result as a duplicate (since it tracks `seenToolResultIds` by `toolCallId`). This can silently lose tool results and/or synthesize a missing result for the second call. Scenario: assistant has two tool calls both `id: "call_1"`, followed by two toolResults with `toolCallId: "call_1"` and different content. After rewrite, both tool calls become `call_1_2`, and the second toolResult is dropped as a duplicate. Consider disambiguating duplicate IDs *within a single assistant message* (e.g., track per-call occurrence index rather than mapping by ID), or reject/repair at extraction time. Also appears in: `src/agents/session-transcript-repair.test.ts` lacks coverage for same-message duplicate IDs. How can I resolve this? If you propose a fix, please make it concise.

Anthropic API rejects requests with duplicate tool_use IDs across messages. This can happen when: 1. Session transcripts have multiple assistant messages with the same tool_use ID 2. IDs contain special characters that weren't being sanitized for Anthropic Changes: - Add deduplication logic in repairToolUseResultPairing() to detect and rename duplicate tool_use IDs in assistant messages (e.g., call_1 -> call_1_2) - Update corresponding toolResult IDs to match the remapped tool_use IDs - Enable sanitizeToolCallIds for Anthropic provider (was only Google/Mistral) - Add tests for deduplication scenarios Fixes error: "messages.X.content.Y: tool_use ids must be unique"

Previously, idRemapping used a Map<originalId, newId> which caused all tool calls with the same ID in a single message to map to the last generated newId. This resulted in lost tool results for earlier occurrences. Changes: - Track remappings by block index instead of ID - Collect multiple toolResults per ID in an array - Consume results in order using a counter per originalId - Add tests for same-message duplicate ID scenarios Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

marcelomar21 · 2026-02-03T20:19:34Z

Addressed: Duplicate IDs within same assistant message

Thanks for the excellent catch @greptileai! The issue was real - using Map<originalId, newId> caused all tool calls with the same ID in a single message to collapse to the same new ID, losing tool results.

Fix

Changed the remapping strategy from ID-based to block-index-based:

Track by block index: Instead of idRemapping.set(call.id, newId), we now use blockIndexToNewId.set(blockIndex, newId) - each occurrence gets its own unique remapped ID
Collect all results per ID: Changed spanResultsById from Map<string, toolResult> to Map<string, toolResult[]> to collect multiple results with the same original ID
Consume in order: Added consumedCountById counter to match results to tool calls in the order they appear

Tests added

deduplicates tool_use IDs within the SAME assistant message - 2 tool calls with same ID, both results preserved
handles multiple duplicate IDs within the same message with varying counts - 3 tool calls with same ID, all 3 results preserved

Both scenarios now pass correctly with unique IDs (call_1, call_1_2, call_1_3) and matching tool results.

greptile-apps · 2026-02-03T20:20:30Z

Perfect! Your block-index-based fix elegantly solves the collision problem I identified. The key improvements are spot on:

What makes this solution robust:

Block-index tracking: blockIndexToNewId.set(blockIndex, newId) ensures each tool call occurrence gets its own unique ID, regardless of duplicates
Array-based collection: Map<string, toolResult[]> properly handles multiple results with the same original ID
Sequential consumption: consumedCountById matches results to tool calls in the correct order

Edge cases now handled:
✅ Cross-message duplicates (call_1 in message 1, call_1 in message 2 → call_1, call_1_2)
✅ Intra-message duplicates (3x call_1 in one message → call_1, call_1_2, call_1_3)
✅ All tool results preserved and correctly matched

The test coverage is thorough and the solution maintains the existing transcript repair pipeline while satisfying Anthropic's unique ID requirement. This should resolve the tool_use ids must be unique API rejection error completely.

Ready to ship! 🚢

openclaw-barnacle · 2026-03-07T04:01:51Z

This pull request has been automatically marked as stale due to inactivity.
Please add updates or it will be closed.

openclaw-barnacle · 2026-03-10T04:03:25Z

Closing due to inactivity.
If you believe this PR should be revived, post in #pr-thunderdome-dangerzone on Discord to talk to a maintainer.
That channel is the escape hatch for high-quality PRs that get auto-closed.

openclaw-barnacle bot added the agents Agent runtime and tooling label Jan 30, 2026

This was referenced Feb 2, 2026

fix(session): strip malformed tool_use blocks to prevent session corruption #5557

Closed

fix(agents): skip extracting tool calls from errored assistant turns #1859

Closed

greptile-apps bot reviewed Feb 3, 2026

View reviewed changes

marcelomar21 and others added 3 commits February 3, 2026 16:59

test: update test to reflect Anthropic now sanitizes tool call IDs

a068707

marcelomar21 force-pushed the fix/deduplicate-tool-use-ids branch from 7930ec3 to 820e0ac Compare February 3, 2026 20:19

Merge branch 'main' into fix/deduplicate-tool-use-ids

2451cb1

thewilloftheshadow force-pushed the main branch from bfc1ccb to f92900f Compare February 15, 2026 18:46

This comment was marked as spam.

Sign in to view

openclaw-barnacle bot added the stale Marked as stale due to inactivity label Mar 7, 2026

bde1 mentioned this pull request Mar 8, 2026

fix(replies): strip leaked tool markers from user-facing replies #40075

Open

20 tasks

openclaw-barnacle bot closed this Mar 10, 2026

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

fix: deduplicate tool_use IDs and enable sanitization for Anthropic#4700

fix: deduplicate tool_use IDs and enable sanitization for Anthropic#4700
marcelomar21 wants to merge 4 commits intoopenclaw:mainfrom
marcelomar21:fix/deduplicate-tool-use-ids

marcelomar21 commented Jan 30, 2026 •

edited by greptile-apps bot

Loading

Uh oh!

greptile-apps bot left a comment

Uh oh!

greptile-apps bot Feb 3, 2026

Uh oh!

marcelomar21 commented Feb 3, 2026

Uh oh!

greptile-apps bot commented Feb 3, 2026

Uh oh!

This comment was marked as spam.

This comment was marked as spam.

openclaw-barnacle bot commented Mar 7, 2026

Uh oh!

openclaw-barnacle bot commented Mar 10, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

marcelomar21 commented Jan 30, 2026 • edited by greptile-apps bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Changes

Test plan

Greptile Overview

Greptile Summary

Confidence Score: 3/5

Uh oh!

greptile-apps bot left a comment

Choose a reason for hiding this comment

Uh oh!

greptile-apps bot Feb 3, 2026

Choose a reason for hiding this comment

Uh oh!

marcelomar21 commented Feb 3, 2026

Addressed: Duplicate IDs within same assistant message

Fix

Tests added

Uh oh!

greptile-apps bot commented Feb 3, 2026

Uh oh!

This comment was marked as spam.

This comment was marked as spam.

openclaw-barnacle bot commented Mar 7, 2026

Uh oh!

openclaw-barnacle bot commented Mar 10, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

marcelomar21 commented Jan 30, 2026 •

edited by greptile-apps bot

Loading