Python: always_require tool approval silently bypassed when preceded by a declaration-only or unknown call in the same batch

Description

In the Python core, a tool configured with approval_mode="always_require" can be silently bypassed (executed or returned as user input without surfacing an approval request) when another call precedes it in the same model tool-call batch. The approval outcome depends on the position of the call within the batch rather than on the call itself.

Root cause

_try_execute_function_call_groups in python/packages/core/agent_framework/_tools.py classifies the batch with a loop that stops at the first matching call:

for function_call in actionable_calls:
    function_name = function_call.name
    if function_name in approval_tool_names:
        requires_approval = True
        break
    if function_name in declaration_only_tool_names or function_name in additional_tool_names:
        has_declaration_only_call = True
        break
    if config.get("terminate_on_unknown_calls", False) and function_name not in tool_map:
        raise KeyError(f'Error: Requested function "{function_name}" not found.')

Because each branch breaks (or raises) at the first hit, classification travels with the call's position, not with the call:

A declaration-only call appearing before an always_require call makes the whole batch classified as declaration-only user input, so the approval gate is never surfaced.
With terminate_on_unknown_calls=True, an unknown call appearing before an always_require call raises KeyError first, so the higher-priority approval pause is never reached.

Reproduction

Model returns one batch with two calls where a declaration-only (or unknown) call is ordered first and an always_require tool is second. Expected: an approval request is surfaced for the always_require tool. Actual: no approval request; the batch is returned as user input (declaration-first) or terminated with KeyError (unknown-first).

Expected invariant

Approval enforcement must be independent of call order within a batch. Classification should scan the whole batch and apply a fixed priority: approval pause > declaration-only user-input > unknown-call termination.

Scope

python/packages/core/agent_framework/_tools.py batch classification in _try_execute_function_call_groups. Verified present on current main.

Note: this is distinct from #6385 (which concerned the opposite direction, never_require tools being over-approved) and from #7881 (a concurrency-groups feature that retains the current order-dependent classification).

I'm working on a fix with regression tests and will open a PR shortly with Fixes #NNNN.

Confirmed on current main, and there is a nice smoking gun: the comment right above the loop says "A user-input pause takes precedence over unknown-call termination in mixed batches", but the break-on-first-hit loop cannot honor that invariant unless the pause-worthy call happens to come first. All three orderings are broken the way you describe: declaration-only before always_require masks the approval, unknown before always_require (or before declaration-only) raises KeyError before the pause is ever considered.

Fix I would ship: scan the whole batch with explicit precedence instead of first-hit-wins. Collect requires_approval / has_declaration_only_call across all actionable calls (approval short-circuits only upward), and evaluate terminate_on_unknown_calls only after, when neither pause classification fired. That makes the code match its own comment, and single-classification batches behave exactly as before. Tests: the two masked orderings from your report, the unknown+terminate mixed batch, and the pure unknown+terminate case still raising. Happy to open the issue-linked draft.

One process note before I open anything: the function-calling-loop spec (docs/specs/004) asks external contributors to check with the core team before implementing in this area, so I am holding the draft until someone from the team confirms the intended precedence and the affected scenario-matrix rows.

The fix and regression tests are ready locally and follow the shape above: whole-batch classification with explicit precedence (approval > declaration-only pause > unknown-call termination), unknowns fatal only when neither pause fired. Tests pin the two masked orderings, the unknown+terminate mixed batch, and that a lone unknown call still raises. Happy to open the issue-linked draft the moment the team gives direction.

Thanks for calling out the ownership guidance. I had already opened #8080 with the reproduction and regression coverage, but the core team should confirm the intended precedence, affected scenario-matrix rows, and validation scope before this moves forward. I've converted the PR to draft and will hold it there. Happy to adjust or step back based on the team's direction; this should also avoid duplicate implementations.

Status update for the core team's precedence call: I verified #8080 locally against current main (red on main's _tools.py for the order-independence and approval-resume tests, green on the branch, no regressions in the full invocation-logic suite) and left the details there. My own draft, which keeps the pause-first reading of the old comment, stays on ice. Whichever precedence the team confirms, the fix shape is ready in one of the two drafts.

🤖 Automated triage reproduction notes (agent-authored — trust but verify)

Agent analysis

Repro: python/packages/core/agent_framework/_tools.py::_try_execute_function_call_groups at lines 178-1804 fails when a declaration-only or unknown call precedes an always_require call in one batch. The declaration-first case emits no approval request, while unknown-first raises KeyError; reversing either ordering surfaces approval. Minimal repro: return those two calls from the mock chat client, enable terminate_on_unknown_calls for the unknown case, and assert an approval request for the second call.

Failing test: python/packages/core/tests/core/test_function_invocation_logic.py::test_always_require_approval_is_independent_of_batch_order
Files examined: python/AGENTS.md, python/packages/core/AGENTS.md, python/packages/core/agent_framework/_tools.py, python/packages/core/tests/core/test_function_invocation_logic.py, docs/specs/004-python-function-calling-loop.md, python/pyproject.toml
Tests run: python/packages/core/tests/core/test_function_invocation_logic.py::test_always_require_approval_is_independent_of_batch_order

I can take this up once the intended precedence is confirmed by the core team.

From the current implementation, I think the safest fix is to make the batch classification independent of call order rather than relying on the first matching call. I would scan the actionable calls first and track the classification flags, then apply the precedence explicitly:

always_require approval > declaration-only user input > unknown-call termination

In particular, an unknown call should not raise immediately if the same batch contains a tool that requires approval, since we need to surface the approval request first.

I’d add regression coverage for:

declaration-only → always_require
always_require → declaration-only
unknown → always_require with terminate_on_unknown_calls=True
unknown → declaration-only with terminate_on_unknown_calls=True
a standalone unknown call still raising as before
existing single-classification batches remaining unchanged

I’m happy to implement this and take ownership of the fix. If the core team is okay with this approach, could you assign the issue to me? I can work from the existing draft/coordinate with the current PR rather than creating a duplicate implementation.

Implemented and pushed in 9899e37.

Fix

The batch classifier now scans all actionable function calls before selecting a control-flow path. This makes approval enforcement independent of the call order within a model tool-call batch.

The resulting precedence is:

always_require approval pause
Declaration-only user-input pause
Unknown-call termination when terminate_on_unknown_calls=True

Regression coverage

Declaration-only call before and after an always_require call
Unknown call before an always_require call with unknown-call termination enabled
Unknown call with a declaration-only sibling
Existing standalone unknown-call termination behavior

Validation

uv run --project . pytest packages/core/tests/core/test_function_invocation_logic.py -q
Passed (2 skipped)

uv run --project . --group dev ruff check packages/core/agent_framework/_tools.py packages/core/tests/core/test_function_invocation_logic.py
All checks passed

I kept this on a separate branch and did not open a duplicate PR because #8080 is already tracking the issue.

Thanks for keeping this on a branch and not opening a duplicate PR. A few coordination points are worth keeping explicit before 9899e37 is treated as the implementation direction:

It selects pause-first precedence (approval > declaration-only > unknown), while Python: fix order-dependent tool-approval bypass in mixed batches #8080 currently implements fail-closed unknown-call precedence. That contract is still awaiting the core team's decision.
The linked commit is based on 6a3633e54 (Aug 17), rather than current main.
It does not cover the approval-resume/declaration-only lifecycle and mixed-pause model-order findings documented in Python: fix order-dependent tool-approval bypass in mixed batches #8080.

Since #8080 is already linked and I have local follow-ups for those paths, let's avoid opening another PR until the core team confirms the precedence and scenario-matrix rows. Once that direction is clear, I'm happy to reconcile useful regression cases into the existing PR and coordinate review.

AEGISORA-W29-MAF

The batch-order approval bug looks like a strong candidate for an execution-boundary invariant.

I would express the expected behavior as:

For a batch of tool calls, approval requirements must be determined from the complete batch, not from whichever call happens to appear first.

Adversarial fixture:

call 1 = declaration-only or unknown
call 2 = always_require tool

Expected:
approval is surfaced for call 2

Security invariant:
no approval-required action may execute merely because an earlier call changed batch classification.

The same fixture can also measure the stronger property:

before = N downstream tool executions
after unauthorized approval bypass attempt = N

That makes the failure observable at the execution boundary rather than only through control-flow state.

We are testing this class of invariant in Aegisora's public runtime-security challenge:

aegisora-ai/aegisora#28

RongJie G (@CorgiBoyG)

Thanks for the clarification, RongJie G (@CorgiBoyG) That makes sense.

I’ll hold off on opening a separate PR and won’t treat 9899e37 as the final implementation direction until the core team confirms the intended precedence and scenario-matrix coverage.

Once the direction is confirmed, I’m happy to rebase my work onto current main, reconcile the additional approval-resume/declaration-only lifecycle cases, and contribute the relevant regression tests to #8080 rather than creating a parallel implementation.

I’ll keep the branch available so the work can be reused if the pause-first precedence is confirmed.

Eray Özer (@ozereray)

Thanks, Eray Özer (@ozereray) ! I agree that the execution boundary is the right place to validate the invariant.

For this issue, I’d keep the primary fix focused on the in-framework guarantee: an always_require tool must not be executable or returned without an approval request simply because another call appeared earlier in the same batch.

An external artifact could be useful as additional evidence, but I think the important contract here is that approval classification is derived from the complete batch and remains independent of call ordering. Once the core team confirms the precedence and scenario matrix, the regression tests in #8080 can make that invariant concrete at the framework level.

Hi Corgi,

Your investigation into approval depending on call position rather than the specific call itself raised an interesting question.

Beyond fixing the ordering issue, there is also a broader challenge: after an approval decision happens, how can we clearly observe that the specific call was the one actually allowed or blocked?

I have been testing a small execution-boundary experiment around this idea — keeping the scope to one local tool call and looking at what can be verified before and after entry.

Would be interested in your thoughts on whether this kind of evidence is useful when reasoning about approval semantics.

Thanks, Mkaliez. I think the distinction you’re drawing is important. For #8079, I would treat the two as complementary but not equivalent: *The primary contract should be in-framework:* approval classification must be derived from the specific tool call and the complete batch context, not from call position or the presence of an earlier unknown/declaration-only call. An always_require tool should therefore never become executable without its own approval request. *The external artifact is the evidence layer:* once the framework has made that decision, an independently readable artifact should make it possible to establish what specific call was allowed or blocked and what was actually observed at the execution boundary. That separation matters because a framework can get the approval semantics right while still producing ambiguous execution evidence, or produce excellent evidence while the authorization itself is wrong. So for this issue I’d prioritize the in-framework guarantee and scenario-matrix regression tests, with the external artifact as a useful way to validate the resulting execution boundary independently. The strongest acceptance case would be the same tool appearing in different positions in the same batch while preserving identical approval semantics, followed by verification that the exact approved call — and only that call — reaches execution. Mkaliez ***@***.***>, 10 Eyl 2026 Per, 20:43 tarihinde şunu yazdı:

…

*MkaliezZ* left a comment (microsoft/agent-framework#8079) <#8079 (comment)> Hi Corgi, Your investigation into approval depending on call position rather than the specific call itself raised an interesting question. Beyond fixing the ordering issue, there is also a broader challenge: after an approval decision happens, how can we clearly observe that the specific call was the one actually allowed or blocked? I have been testing a small execution-boundary experiment around this idea — keeping the scope to one local tool call and looking at what can be verified before and after entry. Would be interested in your thoughts on whether this kind of evidence is useful when reasoning about approval semantics. — Reply to this email directly, view it on GitHub <#8079?email_source=notifications&email_token=A4KE3NWMJCHWHPJEC6Y4W335OLY6VA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNRSGM3TEMJVGY4KM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-5623721568>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A4KE3NQI45UQLP2CNJ7MJNT5OLY6VAVCNFSNUABFKJSXA33TNF2G64TZHM4TONBUGQ2TKOJSHNEXG43VMU5TKMZVGE3DSOBQGQ2KC5QC> . You are receiving this because you were mentioned.Message ID: <microsoft/agent-framework/issues/8079/5623721568 <(562)%20372-1568>@ github.com>

Yeah, that's what I trying to get at. I don't think an evidence layer should compensate for incorrect authorization semantics — the framework has to get that part right first. What I care about at the execution boundary is preserving the second fact independently: which concrete call crossed it, with which effective arguments, and whether the tool body actually started. The same-tool/different-position case seems to be a very clean acceptance fixture for both sides of that boundary. Eray Özer ***@***.***> 于2026年9月11日周五 06:31写道：

…

*ozereray* left a comment (microsoft/agent-framework#8079) <#8079 (comment)> Thanks, Mkaliez. I think the distinction you’re drawing is important. For #8079, I would treat the two as complementary but not equivalent: *The primary contract should be in-framework:* approval classification must be derived from the specific tool call and the complete batch context, not from call position or the presence of an earlier unknown/declaration-only call. An always_require tool should therefore never become executable without its own approval request. *The external artifact is the evidence layer:* once the framework has made that decision, an independently readable artifact should make it possible to establish what specific call was allowed or blocked and what was actually observed at the execution boundary. That separation matters because a framework can get the approval semantics right while still producing ambiguous execution evidence, or produce excellent evidence while the authorization itself is wrong. So for this issue I’d prioritize the in-framework guarantee and scenario-matrix regression tests, with the external artifact as a useful way to validate the resulting execution boundary independently. The strongest acceptance case would be the same tool appearing in different positions in the same batch while preserving identical approval semantics, followed by verification that the exact approved call — and only that call — reaches execution. Mkaliez ***@***.***>, 10 Eyl 2026 Per, 20:43 tarihinde şunu yazdı: > *MkaliezZ* left a comment (microsoft/agent-framework#8079) > < #8079 (comment)> > > Hi Corgi, > > Your investigation into approval depending on call position rather than > the specific call itself raised an interesting question. > > Beyond fixing the ordering issue, there is also a broader challenge: after > an approval decision happens, how can we clearly observe that the specific > call was the one actually allowed or blocked? > > I have been testing a small execution-boundary experiment around this idea > — keeping the scope to one local tool call and looking at what can be > verified before and after entry. > > Would be interested in your thoughts on whether this kind of evidence is > useful when reasoning about approval semantics. > > — > Reply to this email directly, view it on GitHub > < #8079?email_source=notifications&email_token=A4KE3NWMJCHWHPJEC6Y4W335OLY6VA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNRSGM3TEMJVGY4KM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-5623721568>, > or unsubscribe > < https://github.com/notifications/unsubscribe-auth/A4KE3NQI45UQLP2CNJ7MJNT5OLY6VAVCNFSNUABFKJSXA33TNF2G64TZHM4TONBUGQ2TKOJSHNEXG43VMU5TKMZVGE3DSOBQGQ2KC5QC> > . > You are receiving this because you were mentioned.Message ID: > <microsoft/agent-framework/issues/8079/5623721568 <(562)%20372-1568> <(562)%20372-1568>@ > github.com> > — Reply to this email directly, view it on GitHub <#8079?email_source=notifications&email_token=B7VLBE6D5AL7ODAZFJGNXK35OMTTVA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNRSGYZTCMBWGQ2KM4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-5626310644>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/B7VLBEY7GJ5L57KNG6UEVAL5OMTTVAVCNFSNUABFKJSXA33TNF2G64TZHM4TONBUGQ2TKOJSHNEXG43VMU5TKMZVGE3DSOBQGQ2KC5QC> . You are receiving this because you commented.Message ID: <microsoft/agent-framework/issues/8079/5626310644 <(562)%20631-0644>@ github.com>

fix: enforce tool approval regardless of call order in mixed batches

Agreed. I think the two layers now fit together quite cleanly. The framework-level invariant is: batch → classify all calls → apply fixed precedence → require approval for every always_require call and the execution-level invariant is: decision → exact effective call → execution boundary → observed effect What makes #8079 particularly useful is that it gives us a compact cross-layer acceptance case: the *same tool and same effective arguments should produce the same approval requirement regardless of its position in the batch*, and once approved, the evidence should identify the concrete call that actually crossed the execution boundary. That also means the declaration-only / unknown calls should remain classification inputs rather than becoming implicit authorization state for a neighboring call. From the Aegisora side, this is the same separation we care about: *decision correctness first, execution binding second, evidence third*. An artifact should never be used to compensate for an incorrect authorization decision, and an ALLOW should never be treated as proof that the corresponding tool body actually ran. The strongest regression fixture therefore looks like: same batch semantics + reordered calls → identical approval classification → approved call bound to exact execution → explicit evidence of whether the tool body started That gives us a framework-level fix and an execution-level verification without conflating the two. Mkaliez ***@***.***>, 14 Eyl 2026 Pzt, 15:52 tarihinde şunu yazdı:

…

*MkaliezZ* left a comment (microsoft/agent-framework#8079) <#8079 (comment)> Yeah, that's what I trying to get at. I don't think an evidence layer should compensate for incorrect authorization semantics — the framework has to get that part right first. What I care about at the execution boundary is preserving the second fact independently: which concrete call crossed it, with which effective arguments, and whether the tool body actually started. The same-tool/different-position case seems to be a very clean acceptance fixture for both sides of that boundary. Eray Özer ***@***.***> 于2026年9月11日周五 06:31写道： > *ozereray* left a comment (microsoft/agent-framework#8079) > < #8079 (comment)> > Thanks, Mkaliez. I think the distinction you’re drawing is important. > > For #8079, I would treat the two as complementary but not equivalent: > > *The primary contract should be in-framework:* approval classification > must > be derived from the specific tool call and the complete batch context, not > from call position or the presence of an earlier unknown/declaration-only > call. An always_require tool should therefore never become executable > without its own approval request. > > *The external artifact is the evidence layer:* once the framework has made > that decision, an independently readable artifact should make it possible > to establish what specific call was allowed or blocked and what was > actually observed at the execution boundary. > > That separation matters because a framework can get the approval semantics > right while still producing ambiguous execution evidence, or produce > excellent evidence while the authorization itself is wrong. > > So for this issue I’d prioritize the in-framework guarantee and > scenario-matrix regression tests, with the external artifact as a useful > way to validate the resulting execution boundary independently. > > The strongest acceptance case would be the same tool appearing in > different > positions in the same batch while preserving identical approval semantics, > followed by verification that the exact approved call — and only that call > — reaches execution. > > Mkaliez ***@***.***>, 10 Eyl 2026 Per, 20:43 tarihinde şunu > yazdı: > > > *MkaliezZ* left a comment (microsoft/agent-framework#8079) > > < > #8079 (comment)> > > > > > Hi Corgi, > > > > Your investigation into approval depending on call position rather than > > the specific call itself raised an interesting question. > > > > Beyond fixing the ordering issue, there is also a broader challenge: > after > > an approval decision happens, how can we clearly observe that the > specific > > call was the one actually allowed or blocked? > > > > I have been testing a small execution-boundary experiment around this > idea > > — keeping the scope to one local tool call and looking at what can be > > verified before and after entry. > > > > Would be interested in your thoughts on whether this kind of evidence is > > useful when reasoning about approval semantics. > > > > — > > Reply to this email directly, view it on GitHub > > < > #8079?email_source=notifications&email_token=A4KE3NWMJCHWHPJEC6Y4W335OLY6VA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNRSGM3TEMJVGY4KM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-5623721568>, > > > or unsubscribe > > < > https://github.com/notifications/unsubscribe-auth/A4KE3NQI45UQLP2CNJ7MJNT5OLY6VAVCNFSNUABFKJSXA33TNF2G64TZHM4TONBUGQ2TKOJSHNEXG43VMU5TKMZVGE3DSOBQGQ2KC5QC> > > > . > > You are receiving this because you were mentioned.Message ID: > > <microsoft/agent-framework/issues/8079/5623721568 <(562)%20372-1568> <(562)%20372-1568> > <(562)%20372-1568>@ > > github.com> > > > > — > Reply to this email directly, view it on GitHub > < #8079?email_source=notifications&email_token=B7VLBE6D5AL7ODAZFJGNXK35OMTTVA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNRSGYZTCMBWGQ2KM4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-5626310644>, > or unsubscribe > < https://github.com/notifications/unsubscribe-auth/B7VLBEY7GJ5L57KNG6UEVAL5OMTTVAVCNFSNUABFKJSXA33TNF2G64TZHM4TONBUGQ2TKOJSHNEXG43VMU5TKMZVGE3DSOBQGQ2KC5QC> > . > You are receiving this because you commented.Message ID: > <microsoft/agent-framework/issues/8079/5626310644 <(562)%20631-0644> <(562)%20631-0644>@ > github.com> > — Reply to this email directly, view it on GitHub <#8079?email_source=notifications&email_token=A4KE3NT7C55R2V5NANHLX4L5O7Z2TA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNRWGUYDOMJRHAYKM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-5665071180>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A4KE3NVQSSWXNBLZH7MS3RT5O7Z2TAVCNFSNUABFKJSXA33TNF2G64TZHM4TONBUGQ2TKOJSHNEXG43VMU5TKMZVGE3DSOBQGQ2KC5QC> . You are receiving this because you were mentioned.Message ID: <microsoft/agent-framework/issues/8079/5665071180 <(566)%20507-1180>@ github.com>

fix: enforce tool approval regardless of call order in mixed batches

Thanks everyone for the investigation and test suggestions. I implemented a fix in #8428.

The function loop now:

examines every requested function call before acting;
raises immediately if any call requires fatal termination;
otherwise returns approval-required and Host-owned calls as one mixed batch;
keeps calls that do not require approval cached until the batch resumes.

ToolApprovalMiddleware continues to support standing and automatic approval policies. It preserves Host-owned requests in the batch and does not execute cached calls until the required responses are available.

The regression tests cover:

the same calls in different orders producing the same outcome;
fatal unknown calls in every position;
mixed approval and declaration-only calls;
manual and automatic approval policies;
no execution before the complete batch is resolved;
the exact approved arguments executing once;
streaming and non-streaming behavior.

Incomplete mixed responses fail closed and can be retried with the complete response set. The function-calling-loop specification has been updated with this behavior.

It should be the right boundary. The order-invariance and “no execution before the complete batch is resolved” cases are the two I’d especially want to keep as permanent regressions. Eduard van Valkenburg ***@***.***> 于2026年9月16日周三 20:29写道：

…

*eavanvalkenburg* left a comment (microsoft/agent-framework#8079) <#8079 (comment)> Thanks everyone for the investigation and test suggestions. I implemented a fix in #8428 <#8428>. The function loop now: - examines every requested function call before acting; - raises immediately if any call requires fatal termination; - otherwise returns approval-required and Host-owned calls as one mixed batch; - keeps calls that do not require approval cached until the batch resumes. ToolApprovalMiddleware continues to support standing and automatic approval policies. It preserves Host-owned requests in the batch and does not execute cached calls until the required responses are available. The regression tests cover: - the same calls in different orders producing the same outcome; - fatal unknown calls in every position; - mixed approval and declaration-only calls; - manual and automatic approval policies; - no execution before the complete batch is resolved; - the exact approved arguments executing once; - streaming and non-streaming behavior. Incomplete mixed responses fail closed and can be retried with the complete response set. The function-calling-loop specification has been updated with this behavior. — Reply to this email directly, view it on GitHub <#8079?email_source=notifications&email_token=B7VLBE45JZIJY3PP7AMN2OL5PKBSJA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNRZG42DENRQGAY2M4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-5697426001>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/B7VLBEZJTHQ44XBOUCDAJFD5PKBSJAVCNFSNUABFKJSXA33TNF2G64TZHM4TONBUGQ2TKOJSHNEXG43VMU5TKMZVGE3DSOBQGQ2KC5QC> . You are receiving this because you commented.Message ID: ***@***.***>

Navigation Menu

Repository navigation

Python: always_require tool approval silently bypassed when preceded by a declaration-only or unknown call in the same batch #8079

Description

Root cause

Reproduction

Expected invariant

Scope

Fix

Regression coverage

Validation

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Python: always_require tool approval silently bypassed when preceded by a declaration-only or unknown call in the same batch #8079

Description

Description

Root cause

Reproduction

Expected invariant

Scope

Activity

he-yufeng commented on Sep 4, 2026

he-yufeng commented on Sep 4, 2026

CorgiBoyG commented on Sep 5, 2026

he-yufeng commented on Sep 5, 2026

github-actions commented on Sep 7, 2026

Shivani767 commented on Sep 9, 2026

Shivani767 commented on Sep 9, 2026

Fix

Regression coverage

Validation

CorgiBoyG commented on Sep 10, 2026

ozereray commented on Sep 10, 2026

Shivani767 commented on Sep 10, 2026

Shivani767 commented on Sep 10, 2026

MkaliezZ commented on Sep 10, 2026

ozereray commented on Sep 10, 2026

MkaliezZ commented on Sep 14, 2026

ozereray commented on Sep 15, 2026

eavanvalkenburg commented on Sep 16, 2026

MkaliezZ commented on Sep 16, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions