Skip to content

[dotnet-port-api] Align tool approval rule context #505

Description

@github-actions

Summary

Ported the .NET tool-approval auto-approval callback widening from function-call-only input to a richer Go context object.

In agent/harness/toolapproval, Config.AutoApprovalRules now uses the exported toolapproval.ToolAutoApprovalRule callback shape over *toolapproval.ToolAutoApprovalRuleContext, which carries the current function call plus the session, request messages, and run options available to middleware. The middleware now threads that context through both normal approval evaluation and queued-request draining, and the parity doc was updated to reflect the added context surface.

Upstream reference:

Ported .NET PRs

Breaking Changes

Yes.

Old behavior/API:

  • toolapproval.Config.AutoApprovalRules accepted callbacks with signature func(context.Context, *message.FunctionCallContent) (bool, error).

New behavior/API:

  • toolapproval.Config.AutoApprovalRules now accepts toolapproval.ToolAutoApprovalRule callbacks with signature func(context.Context, *toolapproval.ToolAutoApprovalRuleContext) (bool, error).
  • Existing rules must read the tool call from ruleCtx.FunctionCallContent.

Why acceptable:

  • This repo is still in beta, and the change aligns the Go SDK with the upstream .NET public extension point so future context additions can be made without another callback-signature break.

Tests and Examples

  • Ran go test ./agent/harness/toolapproval ./agent/...
  • Ran go test ./...
  • Added coverage for direct auto-approval context propagation and queued-request context propagation
  • No examples changed

Notes

  • This PR intentionally ports only the tool-approval rule-context change from microsoft/agent-framework#7107.
  • Go middleware does not expose a concrete agent instance at this layer, so the new Go context surfaces the session, request messages, and run options that are available to middleware evaluation.
  • Other recent upstream tool-approval and skills changes remain tracked separately (for example the existing bypass opt-out and skills approval work) and were not bundled here.

Generated by .NET to Go API Porting Agent · 591.2 AIC · ⌖ 54.8 AIC · ⊞ 21.7K ·


Note

This was originally intended as a pull request, but GitHub Actions is not permitted to create or approve pull requests in this repository.
The changes have been pushed to branch dotnet-port-toolapproval-rule-context-20260716-3328ba4907b6fb93.

Click here to create the pull request

To fix the permissions issue, go to SettingsActionsGeneral and enable Allow GitHub Actions to create and approve pull requests. See also: gh-aw FAQ

Show patch preview (444 of 444 lines)
From 203b0e9ccf5854bb09a3ec6337f9d04b4c8d6286 Mon Sep 17 00:00:00 2001
From: "github-actions[bot]" <github-actions[bot]@users.noreply.github.com>
Date: Thu, 16 Jul 2026 06:15:44 +0000
Subject: [PATCH] [dotnet-port-api] Align tool approval rule context

Port .NET PR #7107 by widening toolapproval auto-approval rules to receive a ToolAutoApprovalRuleContext with request/session/run-option state.

Add focused tests for context propagation during direct and queued approval evaluation, and update the parity documentation.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
---
 agent/harness/toolapproval/toolapproval.go    |  67 ++++--
 .../harness/toolapproval/toolapproval_test.go | 193 ++++++++++++++++--
 docs/dotnet-go-sdk-feature-comparison.md      |   2 +-
 3 files changed, 226 insertions(+), 36 deletions(-)

diff --git a/agent/harness/toolapproval/toolapproval.go b/agent/harness/toolapproval/toolapproval.go
index b277204b3..ae05197d8 100644
--- a/agent/harness/toolapproval/toolapproval.go
+++ b/agent/harness/toolapproval/toolapproval.go
@@ -37,6 +37,26 @@ type Rule struct {
 	Arguments map[string]string `json:"arguments"`
 }
 
+// ToolAutoApprovalRule evaluates whether a tool call should be auto-approved.
+type ToolAutoApprovalRule func(context.Context, *ToolAutoApprovalRuleContext) (bool, error)
+
+// ToolAutoApprovalRuleContext describes the tool call being evaluated together
+// with the surrounding run context available to tool-approval middleware.
+type ToolAutoApprovalRuleContext struct {
+	// FunctionCallContent is the tool call that requires approval.
+	FunctionCallContent *message.FunctionCallContent
+
+	// Session is the current run session, if any.
+	Session *agent.Session
+
+	// RequestMessages are the messages passed into the current middleware
+	// invocation or queued-request drain evaluation.
+	RequestMessages []*message.Message
+
+	// RunOptions are the options visible to the current middleware evaluation.
+	RunOptions []agent.Opt
... (truncated)

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions