Use of `deepcopy_minimal` in `files.beta.upload` mutates dict in place

[proco-company]

Hello all,

We have noticed that the files.beta.upload was mutating in-place some elements of the File parameter we were passing as arguement to the said function.

In particular we were passing a tuple of the form Tuple[Optional[str], FileContent, Optional[str], Mapping[str, str]], which you can see in

anthropic-sdk-python/src/anthropic/_types.py

Line 77 in 7a6c642

Tuple[Optional[str], FileContent, Optional[str], Mapping[str, str]],

is a legal entry for the FileTypes type.

The problem arises in the fact that deepcopy_minimal does not recursively copy anything except lists or dicts. AS such, when it encoutners the tuple that composes the entire object it stops. However this means the 4th element of this tupel (a mapping) may be mutated in-place and returned to the original caller (in this case, me) changed.

https://github.com/anthropics/anthropic-sdk-python/blob/main/src/anthropic/_utils/_utils.py#L187

I have verified empirically this is the case (indeed it was a bug that initially drew my attention to this issue) with a simple experiment that shows in this case the "headers" dict that makes up part of the file entry has been modified in place.

IN any case, the bug can be easily avoided on our side and I have fixed it but I thought I would raise the issue since I assume this would not be the intended behavior of the files.beta.upload method. I have not yet checked the other usages of deepcopy_minimal but I would advise someone check that in case there are other such corner cases. My suggestion would be to change the function to admit recurison on tuples as well but you likely know your system better than I do.

Cheer!

anthropic-sdk-python/src/anthropic/resources/beta/files.py

Line 314 in 7a6c642

body = deepcopy_minimal({"file": file})

[proco-company]

(Of course in the attached screenshot the bug on our side can be fixed by resetting the header dict each time, but it serves to illustrate the problem of unexpected in-place mutation of an argument)

[xXMrNidaXx]

Nice catch — tuple-containing dicts getting mutated is a subtle but real problem.

Root Cause Analysis

Looking at deepcopy_minimal:

def deepcopy_minimal(item: _T) -> _T:
    if isinstance(item, dict):
        return cast(_T, {k: deepcopy_minimal(v) for k, v in item.items()})
    if isinstance(item, list):
        return cast(_T, [deepcopy_minimal(entry) for entry in item])
    return item  # ❌ Tuples returned as-is, their contents not copied

When you pass Tuple[str, FileContent, str, Mapping[str, str]], the tuple is returned unchanged (not recursed into), so the 4th element (your headers dict) is the same object as your input.

The Fix

Add tuple recursion:

def deepcopy_minimal(item: _T) -> _T:
    if isinstance(item, dict):
        return cast(_T, {k: deepcopy_minimal(v) for k, v in item.items()})
    if isinstance(item, list):
        return cast(_T, [deepcopy_minimal(entry) for entry in item])
    if isinstance(item, tuple):
        return cast(_T, tuple(deepcopy_minimal(entry) for entry in item))
    return item

Edge case: Named tuples should probably be handled separately to preserve their type:

if isinstance(item, tuple):
    if hasattr(item, '_fields'):  # NamedTuple
        return cast(_T, type(item)(*(deepcopy_minimal(e) for e in item)))
    return cast(_T, tuple(deepcopy_minimal(entry) for entry in item))

Other deepcopy_minimal usages to audit:

The function is used in:

• _base_client.py — request options handling
• _response.py — response parsing
• Various beta/ endpoints

Any code path that accepts tuple-containing types (FileTypes, Iterables of tuples) could hit this.

Since this is Stainless-generated, the fix may need to happen upstream. Happy to test a PR if one gets opened.

---

At RevolutionAI we've been bitten by similar copy-semantics issues in SDK integrations. Thanks for the clear repro!

[xXMrNidaXx]

Thanks for digging into this! The root cause is clear: deepcopy_minimal only handles lists/dicts, so tuples (and their mutable contents) get passed by reference.

Quick workaround until this is patched:

from copy import deepcopy

# Wrap your file tuple before passing to upload
file_copy = deepcopy(my_file_tuple)
client.files.beta.upload(file=file_copy)

Suggested fix for the SDK:

The deepcopy_minimal function should handle tuples recursively:

def deepcopy_minimal(item: _T) -> _T:
    if isinstance(item, dict):
        return {k: deepcopy_minimal(v) for k, v in item.items()}
    elif isinstance(item, list):
        return [deepcopy_minimal(x) for x in item]
    elif isinstance(item, tuple):
        return tuple(deepcopy_minimal(x) for x in item)  # Add this case
    return item

This would preserve the tuple structure while properly copying nested mutable objects like the headers dict you mentioned.

Would be happy to submit a PR if the maintainers want community contribution here.

[Bortlesboat]

The deepcopy_minimal function looks like it comes from the Stainless SDK generator template (identical code exists in openai-python at the same path). A fix here would likely get overwritten on the next SDK regeneration. This probably needs to be fixed upstream in the Stainless template so it propagates to all generated SDKs.