cast(bool, x) is a promise to the type checker. At runtime it is the identity function.

In google/adk-python, the value that decides whether a tool call needs human confirmation reaches its caller through cast(bool, await ...).

typing.cast returns its second argument. That is the entire implementation. It exists so a static checker will stop complaining, and it does nothing at all when the program runs. If the awaited expression produces None, the caller receives None. The caller then tests it for truth and skips the confirmation.

That is the same ending as the coercion defect filed against openai-agents-python as issue #4845. Different route. This one arrives by declaration instead of by conversion.

Why a static analyser has nothing to say

Ask a type checker what cast(bool, x) is and it answers bool. Correctly. That is what cast is for. The programmer asserted the type and the checker took the assertion. There is no diagnostic to emit and no line to highlight.

A grep-shaped tool has a different problem: the pair is not on one line. Formatters split cast( from bool, across a newline, so a per-line pattern never sees them together. I had to look at a window of lines rather than at single lines.

What I got wrong

Two things, and the second is the embarrassing one.

I first recorded the sites as function_tool.py:206 and mcp_tool.py:474. Those lines read return bool(self._require_confirmation), which is the safe branch. The expression that matters is a few lines above each of them, spanning :202-205 and :470-473. I recorded, and reported, the location of the code that was fine.

The reason I landed there is that my tool did find those functions, and it found them for a reason I never checked. A coercion signal had matched bool(...) on the safe branch. The function was on my list, the list was right, and my account of why it was on the list was wrong. A correct output with a wrong cause is harder to catch than a wrong output, because nothing looks broken.

The same tool was also printing a banner that named two active signals while three were running. I fixed that by printing the signal set the run actually used. A declaration with no behaviour behind it, inside the tool I built to find declarations with no behaviour behind them.

What I did not check

Whether any caller in adk-python actually passes something that resolves to None. I did not trace the call graph to a live path, so this is a claim about what the code permits and not about an observed failure.

cast is not the defect. A cast over a value that has already been checked is fine and common. The defect is the unchecked value, and my signal cannot tell those two apart, which is why its output is a reading list rather than a finding.

I have not measured how common this spelling is across the ecosystem. One repository, one commit, two sites.

Trace: ledger bands/decisions/01_RULINGS.md entries D-G013 and D-G015; scan artifact offer/scans/adk-python.json.

Repository: crates/gx-witness is the part of the project that exists because a claim about a value is not the same as evidence about it.

Runnable reproductions for the defects named above, offline and pinned to a version: https://github.com/mahirhir/unanswered-approval

Comments

[Vinh Nguyen]

There's a neighbouring spelling where the source really does contain a check and it still lands where the cast lands. assert isinstance(flag, bool) reads as evidence to a reviewer, and under python -O it isn't there. I ran the two next to each other on 3.14.6: without -O the assert version raises on None, with -O it returns "skip" for None exactly like cast(bool, None) does. Same permissive direction ahmetozel points at, and the thing deciding which of the two behaviours you get isn't in the file — it's a flag on the process that started it.

That one is worse for a reading list than the cast is, because there's nothing to read. A cast is at least visible as a claim the author can't be held to, and you can go look at it. An assert under -O looks like the check you wanted it to be, and whether it is one depends on how the container was launched.

[Ahmet Özel]

What makes this class of bug nasty is that the failure lands on the permissive side. None is falsy, the confirmation is skipped, and the tool call proceeds - so the bug only manifests as an action nobody approved, which is the outcome least likely to raise an exception and most likely to be noticed later by a human wondering why something ran. A cast is a claim the author cannot be held to, and the place that hurts is exactly where the value crosses an await boundary and the actual provenance is two layers away. The point about formatters splitting cast( from bool, across lines is worth more attention than it usually gets - a lot of these patterns are invisible to line-based tooling and only show up if you look at an AST or a multi-line window, which is why they survive review and CI both.