Ruiming Zhao
2054d62702
* fix(github-copilot): forward telemetry config to client * Python: fix telemetry settings typing for github_copilot `load_settings` does not coerce dict-typed fields, so GITHUB_COPILOT_TELEMETRY and .env values reach the agent as plain strings. Declaring `GitHubCopilotSettings.telemetry` as `dict[str, Any]` therefore misstated the runtime contract and failed the test typing checks where a string is assigned. Widen the annotation to `dict[str, Any] | str | None` and fix the union arm resolution in `_check_override_type`: parameterized generics are not `type` instances, so they were dropped from the allowed set and a valid dict override was rejected at runtime. Arms without a runtime class, such as `Literal`, now skip validation instead of narrowing it incorrectly. Also drive the telemetry string tests through the documented environment variable path rather than mutating `_settings` directly, and cover the valid-JSON-but-not-an-object case. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 657d2953-4112-4a01-889b-c0c6863630c1 * Python: resolve settings override types through generic origins Python 3.10 reports parameterized generics such as `dict[str, Any]` as instances of `type`, so the union arm resolution kept the alias and `isinstance` raised `TypeError: isinstance() argument 2 cannot be a parameterized generic` on that interpreter. Resolve every annotation through `get_origin` first via a shared `_runtime_class` helper, which also removes the same latent failure for a non-union parameterized generic field, and return `None` for annotations such as `Literal[...]` that have no runtime class so validation is skipped rather than narrowed incorrectly. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 657d2953-4112-4a01-889b-c0c6863630c1 --------- Co-authored-by: Giles Odigwe <gilesodigwe@microsoft.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 657d2953-4112-4a01-889b-c0c6863630c1
Get Started with Microsoft Agent Framework GitHub Copilot
Please install this package via pip:
pip install agent-framework-github-copilot
GitHub Copilot Agent
The GitHub Copilot agent enables integration with GitHub Copilot, allowing you to interact with Copilot's agentic capabilities through the Agent Framework.
Tool approval (approval_mode="always_require")
The GitHub Copilot SDK owns the tool-calling loop for this provider, so approval for custom function tools is enforced through the SDK's native pre-execution hook rather than the standard Agent Framework approval round-trip.
When you register a FunctionTool declared with approval_mode="always_require" and you
do not supply your own on_pre_tool_use hook, GitHubCopilotAgent installs a default
on_pre_tool_use hook that returns "ask" for that tool and defers (None) for all other
tools. The "ask" decision routes to your on_permission_request handler, where you
approve or deny the call:
from agent_framework import tool
from agent_framework.github import GitHubCopilotAgent, GitHubCopilotOptions
from copilot.session import PermissionHandler
@tool(approval_mode="always_require")
def delete_file(path: str) -> str:
"""Delete a file."""
...
agent = GitHubCopilotAgent(
tools=[delete_file],
# The "ask" decision is routed here; approve or deny the call.
default_options=GitHubCopilotOptions(on_permission_request=PermissionHandler.approve_all),
)
⚠️ If you provide your own
on_pre_tool_usehook, it takes precedence and the agent does not install its default approval hook. In that case you are fully responsible for enforcing approval — including for anyapproval_mode="always_require"tool (e.g. by returning a"deny"or"ask"decision). The agent logs a warning naming any approval-required tool that your hook must handle.Note: with the default (deny-all) permission handler, an
always_requiretool is denied unless you wire an approvingon_permission_request.
Approving for the rest of the session
PermissionDecisionApproveForSession scopes its approval with either an approval (tool
prompts) or a domain (URL prompts). Both are optional, so a bare
PermissionDecisionApproveForSession() carries no scope at all and the Copilot CLI cannot
interpret it.
GitHubCopilotAgent therefore scopes such a decision automatically, using the request that
triggered it — a shell prompt becomes an approval for that prompt's command identifiers, an
MCP prompt an approval for that server and tool, a URL prompt an approval for that URL's
domain, and so on:
from copilot.generated.rpc import PermissionDecisionApproveForSession
def on_permission_request(request, invocation):
# Scoped to `request` automatically; approves that kind of call for the whole session.
return PermissionDecisionApproveForSession()
The decision is only ever narrowed, never widened. When the prompt reports that it cannot
offer session-scoped approval (can_offer_session_approval=False), or the request kind has
no session-scoped approval at all (such as a hook prompt), the decision is downgraded to a
single-use approval and a warning is logged. Pass an explicit approval= or domain= when
you want to approve something other than the request being handled — decisions that already
specify a scope are forwarded unchanged.
Deprecated: on_function_approval
The on_function_approval callback is deprecated. It still works (and is still enforced
inside the tool handler for backward compatibility), but it emits a DeprecationWarning and
will be removed in a future version. Migrate to the on_pre_tool_use + on_permission_request
model described above. When on_function_approval is set, it gates always_require tools and
the default ask-hook is not installed. It is mutually exclusive with on_pre_tool_use —
setting both (whether at construction or per run) raises ValueError.