Automated sync from private repo (2026-06-10)#770
Merged
foundry-samples-repo-sync[bot] merged 5 commits intoJun 10, 2026
Conversation
* Voice agent with foreground router and background workers * Update the env var for Foundry deployment * Update invocations_ws README and address copilot review comments * Address copilot comments * Update agent description Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> --------- Co-authored-by: Jian Miao <jianm@microsoft.com> Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
#511) Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
* Add C# toolbox auth-paths hosted-agent sample and wire cloud E2E
Add samples/csharp/hosted-agents/agent-framework/toolbox-auth-paths, an
Agent Framework hosted agent that loads a multi-tool Foundry Toolbox
demonstrating the authentication paths a toolbox MCP tool can use to
reach its upstream server: key-based (CustomKeys connection) and public
no-auth. Foundry resolves each tool credential server-side, so the agent
code carries no auth logic.
Wire the sample into hosted-agents-cloud-e2e.yml as a self-provisioning
cell. A guarded self_provision flag (set only for this sample) forces a
single matrix cell instead of the toolbox cartesian product, runs azd
provision so the connection and toolbox are created from the manifest
resources, sources the provisioning PAT from the GH_PAT secret, and
fails fast when no real PAT is configured. Teardown stays gated on
SKIP_PROVISION to match the shared project status quo.
Add the CI invoke payload under internal/tools/samples-hosted-agents and
list the sample in the agent-framework README sample index.
* Drop self-provision CI path and remove no-auth toolbox entry
Revert hosted-agents-cloud-e2e.yml to origin/main: the self_provision
flag was a net-new strategy with no precedent in CI. Toolbox samples run
with SKIP_PROVISION=true and consume a toolbox pre-registered in the
TOOLBOX_ENDPOINT repo variable (like langgraph-toolbox), so no PAT is
provisioned in CI.
Remove the public no-auth path from toolbox-auth-paths: an auth sample
should only demonstrate authenticated paths. Toolbox now exposes only the
key-based CustomKeys GitHub tool; Entra agent identity stays documented.
Rework the sample README to be developer-runnable (azd provision or manual
toolbox creation in your own project) and document the out-of-band CI
registration without naming individuals. Interacting section now uses
azd ai agent invoke --local. Trim payloads to the github prompts.
* Remove redundant test-payload.txt from toolbox-auth-paths sample
CI reads invoke prompts from internal/tools/samples-hosted-agents, and
the build context strips test-payload.txt, so the sample-dir copy is
unused. Drop it and fix the dangling README link.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Rename github_pat secret parameter to gh_pat in toolbox-auth-paths
GitHub forbids creating secrets/variables whose names start with the
GITHUB_ prefix (case-insensitive), and azd resolves a manifest secret
parameter from an env var of the same name. The github_pat parameter
therefore could not be wired in the e2e Foundry project.
Rename the parameter (and its {{ }} placeholder) to gh_pat, matching the
existing GH_PAT secret already used by the cloud-e2e workflow. The
scaffold step now exports both github_pat (other toolbox samples) and
gh_pat. Docs updated; token-format mentions (github_pat_...) left intact.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Fix gh_pat secret resolution in cloud-e2e scaffold (uppercase env var)
azd ai agent init --no-prompt resolves a manifest secret parameter from an
env var named after the parameter UPPERCASED (gh_pat -> GH_PAT). The scaffold
step set a lowercase gh_pat env var, so azd could not find it and failed with
'unable to prompt for secret parameter gh_pat in no-prompt mode'.
Set GH_PAT (uppercase) instead and correct the explanatory comment. The
manifest parameter stays lowercase gh_pat; azd uppercases it to find GH_PAT.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Use map form for gh_pat secret parameter so azd resolves it
azd ai agent init --no-prompt only binds a manifest secret parameter to an
env var when parameters use the map form (parameters: <name>:). The
toolbox-auth-paths manifest used the array form (parameters: properties:
- name:), where 'secret' is not a schema field, so azd recognized the
parameter name but never looked up its env var — failing with 'unable to
prompt for secret parameter gh_pat in no-prompt mode' regardless of the env
var set.
Switch to the map form (matching the browser-automation/langgraph-toolbox
samples). Also export a lowercase gh_pat env var alongside GH_PAT so azd
resolves the value whether it uppercases the parameter name or not.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Drop lowercase gh_pat env var (case-collides with GH_PAT)
GitHub rejects a workflow whose env block defines names differing only by
case (GH_PAT vs gh_pat) -> 'workflow file issue', no jobs run. Keep only the
uppercase GH_PAT, which is what azd resolves the gh_pat secret parameter from
(azd uppercases the parameter name).
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Exclude toolbox-auth-paths x code-interpreter combo (known SDK bug)
The csharp code-interpreter combo triggers an 'invalid_payload' on
/tools/0/container (container serialized as null) — a known .NET Agent
Framework SDK bug in Microsoft.Agents.AI.Foundry.Hosting that cannot be
fixed from this repo. The matrix already excludes this combo for the
sibling foundry-toolbox-server-side sample; add the new toolbox-auth-paths
sample to the same exclusion so the matrix doesn't gate on the known defect.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Rework toolbox-auth-paths to AddFoundryToolboxes (latest Hosting SDK)
The sample pinned Microsoft.Agents.AI.Foundry.Hosting 1.3.0-preview and used
GetToolboxToolsAsync() to pass the toolbox's tools to the agent as server-side
MCP tools. Those tools default to AlwaysRequire approval, so the model's tool
call returned an unhandled approval request and the hosted handler dropped it —
the agent responded with an empty output (silent), even though CI marked it
'completed'.
Bump to the latest 1.9.0-preview and adopt the AddFoundryToolboxes pattern
(matching the AF repo Hosted-Toolbox sample). The hosting layer now connects to
the toolbox MCP proxy at startup and exposes its tools as host-executed
functions — no server-side approval gate — so the agent actually calls the tool
and returns a real answer.
Verified locally against a Foundry project: POST /responses now returns
function_call + function_call_output + a text message (was output: []).
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Derive toolset endpoint from project endpoint when not injected
The previous run revealed the CI hosted container does NOT inject
FOUNDRY_AGENT_TOOLSET_ENDPOINT, so AddFoundryToolboxes disabled toolbox
support and the agent answered from the model alone (a hallucinated, toolless
response that still passed CI). Derive FOUNDRY_AGENT_TOOLSET_ENDPOINT from
FOUNDRY_PROJECT_ENDPOINT (<project>/toolboxes) when the platform doesn't set
it, so the toolbox actually loads.
Verified locally: with only FOUNDRY_PROJECT_ENDPOINT set, the host derives the
toolset endpoint, discovers the toolbox tools, and POST /responses returns
function_call + function_call_output + a text message.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Work around toolbox token audience mismatch (cognitiveservices vs ai.azure.com)
CI showed the toolbox failing to connect with 401 'audience is incorrect
(https://ai.azure.com)'. The Hosting SDK's toolbox token handler requests a
https://cognitiveservices.azure.com token, but the Foundry toolbox MCP proxy
(both the test project and the CI project) requires https://ai.azure.com — so
the toolbox silently failed to load and the agent answered from the model alone.
Register a TokenCredential for the toolbox connection that maps the
cognitiveservices.azure.com audience to ai.azure.com. Verified locally against a
Foundry project: the toolbox now discovers its tools and POST /responses returns
function_call + function_call_output + a text message grounded in the tool.
This is a workaround for an SDK audience bug; the proper fix belongs in
Microsoft.Agents.AI.Foundry.Hosting.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Bump MAF Hosting to 1.10.0 and drop toolbox audience workaround
Microsoft.Agents.AI.Foundry.Hosting 1.10.0-preview.260610.1 requests the
correct https://ai.azure.com token audience for the Foundry toolbox MCP
proxy, so the FoundryToolsetCredential audience-rewrite workaround is no
longer needed. Removed the credential, its DI registration, and the now
unused Azure.Core using.
Verified locally against tao-foundry-prj: the toolbox discovers 51 tools
and the agent answers a GitHub search prompt end-to-end (function_call +
function_call_output + message), with no workaround.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
---------
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Resolves a pre-existing private-vs-public divergence at infrastructure/infrastructure-setup-bicep/10-private-network-basic/azuredeploy.json. Public has been on blob b8716c1 (regenerated by an external/hand process to add uniqueString-based foundryName default + the missing Microsoft.CognitiveServices/accounts/projects dependency) since the 2026-06-08 recovery PR #767. Private stayed on blob 840868a (unchanged since PR microsoft-foundry/foundry-samples-pr#18 in 2026-01-28). The divergence surfaced today during deployment validation of PR #513 (sync exclude filtering moved into filter-stream.py): the seed-marks-from-public.sh tree-equivalence check refused to synthesize marks. This morning's reseed (run 27253358355) passed only because the validation gate happened to include this file in SYNC_BLOCKED_PATHS, causing seed-marks' build_dynamic_pathspecs() to exclude it from comparison. This PR converges private onto public's exact blob (byte-identical), so future seed-marks-from-public.sh runs pass without workarounds. Out of scope (filed as follow-up): - main.bicep is identical on both sides; public's azuredeploy.json was hand-regenerated without updating main.bicep, so the source-vs- generated inconsistency exists on public too. Properly regenerating main.bicep + azuredeploy.json together is a separate task. Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
foundry-samples-repo-sync
Bot
deleted the
sync/private-to-public-20260610-212826
branch
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Automated sync from private repo.
Synced commits: 5
Authors: Adi Yadav,Brandon Miller Copilot,Jian Miao Roger Barreto
Validation gate: mode=
none; tracked=0; blocked=0.Rollback point:
c6a10c6ffa00971f90611d7432709e5d36459b71— to revert, force-push this SHA tomainand clear the sync-marks cache.Triggered by:
workflow_dispatchRun: https://github.com/microsoft-foundry/foundry-samples-pr/actions/runs/27307510300