[dotnet-port-api] Port tool approval rule context

[Michelle Clayton (michelle-clayton-work)]

Summary

Aligned Go tool approval auto-approval rules with the richer .NET rule context by adding an exported toolapproval.ToolAutoApprovalRuleContext and toolapproval.AutoApprovalRule, then updating toolapproval.Config.AutoApprovalRules to receive the function call together with agent, session, request-message, and run-option metadata.

The tests were updated to use the new rule signature and now cover that the context carries the expected run metadata when the middleware executes inside an agent.Agent pipeline.

Ported .NET PRs

• .NET: [BREAKING] Graduate ToolApprovalAgent and add ToolAutoApprovalRuleContext agent-framework#7107 - graduate ToolApprovalAgent and add ToolAutoApprovalRuleContext
  • Upstream commit: b3f2e5392350d32835a40455d5069c18cac47a97
  • Link: .NET: [BREAKING] Graduate ToolApprovalAgent and add ToolAutoApprovalRuleContext agent-framework#7107

Breaking Changes

Yes. toolapproval.Config.AutoApprovalRules previously accepted functions with the signature func(context.Context, *message.FunctionCallContent) (bool, error). It now accepts toolapproval.AutoApprovalRule, which receives *toolapproval.ToolAutoApprovalRuleContext and exposes the original function call through FunctionCall plus the surrounding run metadata. This is acceptable because the Go SDK is still in beta and the new shape matches the richer upstream .NET capability.

Tests and Examples

• go test ./agent/harness/toolapproval
• Added coverage for the new auto-approval rule context metadata
• No examples changed; the existing samples do not currently configure AutoApprovalRules

Notes

• Scoped intentionally to the auto-approval rule context parity gap from .NET: [BREAKING] Graduate ToolApprovalAgent and add ToolAutoApprovalRuleContext agent-framework#7107.
• Did not port the broader max-auto-approval-iterations behavior from the same upstream PR in order to keep this nightly change narrow and reviewable.

Generated by .NET to Go API Porting Agent · gpt54 · 180.7 AIC · ⌖ 12.3 AIC · ⊞ 24.2K · ◷

Closes #823

[Copilot]

🟡 Changes recommended

The same ToolAutoApprovalRuleContext pointer is reused across multiple rules, allowing accidental rule side effects via context mutation to influence subsequent rule evaluation.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

This PR ports the richer .NET tool auto-approval rule context into the Go toolapproval middleware by introducing an exported ToolAutoApprovalRuleContext and updating auto-approval rule evaluation to receive surrounding run metadata (agent/session/request messages/options).

Changes:

• Added toolapproval.ToolAutoApprovalRuleContext and toolapproval.AutoApprovalRule, and updated Config.AutoApprovalRules to use the new signature.
• Threaded the original request messages and run options through the middleware so rules can evaluate against run metadata.
• Updated and extended tests to validate the new context (including agent pipeline metadata capture).

File summaries

File	Description
agent/harness/toolapproval/toolapproval.go	Introduces the exported auto-approval rule context/type and passes run metadata into rule evaluation.
agent/harness/toolapproval/toolapproval_test.go	Updates tests for the new rule signature and adds coverage for captured run metadata in the rule context.

Review details

• Files reviewed: 2/2 changed files
• Comments generated: 1
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[github-actions]

Scope: public API, user-visible behavior

Changed Go contract: New exported toolapproval.ToolAutoApprovalRuleContext struct and toolapproval.AutoApprovalRule func type; toolapproval.Config.AutoApprovalRules field type changed from []func(context.Context, *message.FunctionCallContent) (bool, error) to []AutoApprovalRule (breaking change, acceptable per beta status).

Upstream evidence reviewed:

• dotnet/src/Microsoft.Agents.AI/Harness/ToolApproval/ToolAutoApprovalRuleContext.cs — defines FunctionCallContent, Agent, Session, RequestMessages, RunOptions fields.
• dotnet/src/Microsoft.Agents.AI/Harness/ToolApproval/ToolApprovalAgentOptions.cs — AutoApprovalRules now typed as IEnumerable<Func<ToolAutoApprovalRuleContext, ValueTask<bool>>>.
• dotnet/src/Microsoft.Agents.AI/Harness/ToolApproval/ToolApprovalAgent.cs (line ~880) — constructs new ToolAutoApprovalRuleContext(functionCall, this, session, requestMessages, options) when invoking rules.
• MaxAutoApprovalIterations/DefaultMaxAutoApprovalIterations were already present in the Go codebase prior to this PR (confirmed in agent/harness/toolapproval/toolapproval.go), so the PR's decision to scope out that portion of upstream PR 7107 is consistent with existing Go state, not a gap.

Result: aligned. The Go ToolAutoApprovalRuleContext fields (FunctionCall, Agent, Session, RequestMessages, Options) map cleanly to the .NET ToolAutoApprovalRuleContext (FunctionCallContent, Agent, Session, RequestMessages, RunOptions). The Go Agent field being nilable (vs. .NET's non-null constructor-validated Agent) is a reasonable, idiomatic divergence given Go's lack of constructor validation and the documented "nil when unavailable" comment. No examples reference this API, so the breaking signature change has no ripple effect. No parity issues found.

Warning

Firewall blocked 1 domain

The following domain was blocked by the firewall during workflow execution:

• github.com

To allow these domains, add them to the network.allowed list in your workflow frontmatter:

network:
  allowed:
    - defaults
    - "github.com"

See Network Configuration for more information.

Generated by Go API Consistency Review Agent for #967 · copilot · auto · 22.2 AIC · ⌖ 5.78 AIC · ⊞ 9.5K · ◷