mypy 2.4.0

Source: https://github.com/python/mypy
Tag scanned: v2.4.0
Compared with: v2.3.1 (0 signals introduced since)
Files: 1545 scanned, 334 skipped (binary, oversized, or unrecognised)
Signals: 0 critical · 0 warn · 15 info
Scan time: 15.8 s
LLM review: Reviewed by claude-haiku-5-5 (Anthropic): 12 of 12 warn and critical signals; 12 demoted to info.
Disclude version: 4.1.0
Scanned (UTC): 2026-10-22 05:00

Signals

Ordered by severity, then signals introduced in this release. Hidden characters are shown as ⟨U+…⟩.

info ~~warn~~ → info by review unicode-zero-width CHANGELOG.md:4195:1

U+200B ZERO WIDTH SPACE in source (raw pass, confidence 0.75)
```
⟨U+200B⟩Thanks to all mypy contributors who contributed to this release:

- Aleksi Tarvainen
```
likely benign LLM, confidence 0.85 A stray zero-width space precedes a thank-you line in the mypy changelog.
Reasoning
A single zero-width space sits before a paragraph in release notes. This is typical of copy-pasting from a web page and has no evident payload. The snippet shows no hidden instructions or code.
info ~~warn~~ → info by review unicode-zero-width CHANGELOG.md:4286:1

U+200B ZERO WIDTH SPACE in source (raw pass, confidence 0.75)
```
⟨U+200B⟩Thanks to all mypy contributors who contributed to this release:

- Alex Waygood
```
likely benign LLM, confidence 0.85 Another stray zero-width space before a contributor list in the changelog.
Reasoning
Same pattern as the other changelog finding: a zero-width space before a contributor-thanks paragraph in documentation. It looks like an editing artifact, not an obfuscated payload.
info identifier-low-length docs/source/kinds_of_types.rst:19:1

[embedded python] 13 of 32 non-conventional identifiers are single-character (41%) (token pass, confidence 0.50)

info dynamic-execution misc/build-debug-python.sh:32:1

command name is a variable (`$PREFIX`) that this file sets only to plain text (ast pass, confidence 0.40)

make install
$PREFIX/bin/python3 -m pip install virtualenv
$PREFIX/bin/python3 -m virtualenv $VENV
ln -s python3-config $PREFIX/bin/python-config

info dynamic-execution misc/build-debug-python.sh:33:1

command name is a variable (`$PREFIX`) that this file sets only to plain text (ast pass, confidence 0.40)
```
$PREFIX/bin/python3 -m pip install virtualenv
$PREFIX/bin/python3 -m virtualenv $VENV
ln -s python3-config $PREFIX/bin/python-config
```
info ~~warn~~ → info by review dynamic-execution misc/docker/run-wrapper.sh:13:1

command name is a variable (`$@`) not set in this file — the caller or environment decides what runs (ast pass, confidence 0.70)
```
# Run the wrapped command
"$@"
```
likely benign LLM, confidence 0.85 A Docker helper script that executes the command passed in as its arguments.
Reasoning
The script runs "$@" after a comment saying it runs the wrapped command. A wrapper that executes its arguments is its stated purpose, and the caller controls the command. This is ordinary for a Docker run wrapper.
info ~~critical~~ → info by review dynamic-execution misc/incremental_checker.py:69:12

`subprocess.Popen` with `shell=True` and a non-literal command — runtime-determined shell invocation (ast pass, confidence 0.85)
```
def execute(command: list[str], fail_on_error: bool = True) -> tuple[str, str, int]:
    proc = subprocess.Popen(
        " ".join(command), stderr=subprocess.PIPE, stdout=subprocess.PIPE, shell=True
    )
```
likely benign LLM, confidence 0.80 A developer script runs a joined command list through a shell.
Reasoning
The shell=True call joins a command list built by the developer's own tooling. This is a poor practice, but the script is a dev-only checker with no sign of untrusted input or hidden behavior.
info ~~critical~~ → info by review dynamic-execution misc/perf_checker.py:32:12

`subprocess.Popen` with `shell=True` and a non-literal command — runtime-determined shell invocation (ast pass, confidence 0.85)
```
def execute(command: list[str]) -> None:
    proc = subprocess.Popen(
        " ".join(command), stderr=subprocess.PIPE, stdout=subprocess.PIPE, shell=True
    )
```
likely benign LLM, confidence 0.80 A performance-testing dev script runs a joined command through a shell.
Reasoning
This mirrors the incremental checker: a dev-only performance script joins an internal command list and runs it with shell=True. Nothing in the snippet suggests malicious intent.
info ~~warn~~ → info by review dynamic-execution mypy/dmypy/client.py:556:9

`os.system` called with a literal shell command (ast pass, confidence 0.70)
```
        # ( see https://github.com/python/cpython/issues/74261 )
        os.system("")
    if "error" in response:
        fail(response["error"])
```
likely benign LLM, confidence 0.90 An empty os.system call used to enable console ANSI handling.
Reasoning
os.system("") with an empty literal is a well-known trick on Windows to enable ANSI escape processing in the console. The adjacent comment references a CPython issue, which fits that purpose.
info ~~critical~~ → info by review dynamic-import mypy/stubtest.py:226:13

`__import__` called on a non-literal expression (ast pass, confidence 0.70)
```
            # mentioned in __all__
            __import__(module_name, fromlist=["*"])
    return runtime
```
likely benign LLM, confidence 0.90 Stubtest dynamically imports a module by name to compare stubs against runtime.
Reasoning
Stubtest is a type-checking tool that must import arbitrary stub-listed modules by name. The __import__ call with fromlist is the expected mechanism, and the surrounding comment refers to __all__ handling.
info ~~critical~~ → info by review dynamic-execution mypy/test/testdaemon.py:89:18

`subprocess.check_output` with `shell=True` and a non-literal command — runtime-determined shell invocation (ast pass, confidence 0.85)
```
    try:
        output = subprocess.check_output(
            input, shell=True, stderr=subprocess.STDOUT, text=True, cwd=test_temp_dir, env=env
        )
```
likely benign LLM, confidence 0.80 A test helper runs a test command through a shell with a custom environment.
Reasoning
This is a test helper running a shell command with shell=True and a cwd and env setup. The commands come from the test suite itself, so the usage is unsurprising in a test harness.
info ~~critical~~ → info by review dynamic-execution mypyc/external/googletest/src/gtest-death-test.cc:981:3

`execve` called with a non-literal path (ast pass, confidence 0.90)
```
  // one path separator.
  execve(args->argv[0], args->argv, GetEnviron());
  DeathTestAbort(std::string("execve(") + args->argv[0] + ", ...) in " +
                 original_dir + " failed: " +
```
likely benign LLM, confidence 0.90 Vendored googletest calls execve to re-run a test binary for a death test.
Reasoning
This is the vendored googletest death-test implementation. execve on argv[0] is its designed behavior for re-running a test binary, and the code is a known upstream library.
info ~~warn~~ → info by review macro-keyword-override mypyc/lib-rt/vecs/vec_bool.c:10:1

`#define ITEM_C_TYPE char` aliases a C reserved keyword behind a non-keyword macro name (ast pass, confidence 0.85)
```
#define ITEM_TYPE_MAGIC VEC_ITEM_TYPE_BOOL
#define ITEM_C_TYPE char
#define FEATURES Vec_BoolAPI
```
dismissed LLM, confidence 0.90 A C macro selects char as the item type for a boolean vector template.
Reasoning
This is a generated-style C template that defines ITEM_C_TYPE as char for a boolean vector. Mapping a type name through a macro is the normal way to specialize these containers, so the keyword-override signal is a false positive.
info ~~warn~~ → info by review macro-keyword-override mypyc/lib-rt/vecs/vec_float.c:10:1

`#define ITEM_C_TYPE double` aliases a C reserved keyword behind a non-keyword macro name (ast pass, confidence 0.85)
```
#define ITEM_TYPE_MAGIC VEC_ITEM_TYPE_FLOAT
#define ITEM_C_TYPE double
#define FEATURES Vec_FloatAPI
```
dismissed LLM, confidence 0.90 A C macro selects double as the item type for a float vector template.
Reasoning
Identical template pattern to vec_bool.c, here defining ITEM_C_TYPE as double for a float vector. This is ordinary macro-based specialization and not an evasion technique.
info ~~warn~~ → info by review dynamic-execution mypyc/test/test_run.py:134:17

`exec` called on a non-literal expression (ast pass, confidence 0.70)
```
            with open(script_name, "rb") as f:
                exec(f.read(), g)
        finally:
            sys.argv = save_argv
```
likely benign LLM, confidence 0.85 A mypyc test runner execs a test script file in a controlled namespace.
Reasoning
The test runner execs the contents of a test script file it has just opened, which is how mypyc's run tests execute compiled-program fixtures. The script comes from the repo's test data, so this is expected behavior.

Reproduce This Scan

Run disclude locally to verify. Add --format sarif for SARIF output. Add --llm (with an API key in the environment) to include the LLM review.

cargo install disclude --version 4.1.0
git clone https://github.com/python/mypy mypy && cd mypy
git checkout v2.4.0
disclude scan --severity info --diff v2.3.1 .