Skip to content

[Agents Extension] azd ai connection commands — blocked by namespace prefix conflict#8166

Draft
Nathandrake229 wants to merge 2 commits into
mainfrom
naman/azd-ai-namespace-issue
Draft

[Agents Extension] azd ai connection commands — blocked by namespace prefix conflict#8166
Nathandrake229 wants to merge 2 commits into
mainfrom
naman/azd-ai-namespace-issue

Conversation

@Nathandrake229
Copy link
Copy Markdown
Contributor

Namespace ai conflicts with installed ai.* extensions

This PR demonstrates the azd ai connection commands working at the extension binary level, but failing when routed through azd due to a namespace prefix conflict.

Relates to #8100 (Travis's namespace POC)

What this PR does

Changes azure.ai.agents extension namespace from ai.agent to ai, following the pattern in #8100. Adds azd ai connection commands (list, show, create, delete) as a sibling subcommand group alongside agent:

azd ai
├── agent       (init, run, invoke, show, ...)
└── connection  (list, show, create, delete)

The binary works correctly

When invoked directly, the extension binary handles both command groups:

$ azure-ai-agents.exe connection list -p https://e2e-tests-ncus-account.services.ai.azure.com/api/projects/hosted-agents-bugbash

Name                             Kind               Auth Type               Target
----                             ----               ---------               ------
fabric-api                       ApiKey             AAD                     https://api.fabric.microsoft.com/
fabric-mcp                       RemoteTool         UserEntraToken          https://api.fabric.microsoft.com/v1/mcp
...17 connections listed

The problem: azd ai connection does not reach the binary

$ azd ai connection list --project-endpoint https://...

Commands for the ai extension namespace.
Usage
  azd ai [command]
Available Commands
  agent: Ship agents with Microsoft Foundry from your terminal. (Preview)

connection is not visible. azd shows the ai group help instead of forwarding args to the extension.

Root cause

In cli/azd/cmd/extension.go:1835-1889, checkNamespaceConflict rejects prefix overlaps:

// Two namespaces conflict if one is a prefix of the other (e.g., "ai" and "ai.agent").
func namespacesConflict(ns1, ns2 string) (bool, string) {
    if strings.HasPrefix(ns1Lower, ns2Lower+".") {
        return true, "overlapping namespaces"
    }
}

Namespace ai is a prefix of these installed extensions:

  • ai.models (azure.ai.models)
  • ai.finetuning (azure.ai.finetune)
  • ai.builder (microsoft.azd.ai.builder)

Even when the dev build bypasses the install-time conflict check, the runtime routing in cli/azd/cmd/extensions.go:45-87 creates ai as an intermediate group node (because other ai.* extensions exist). The group node only knows about agent as a child — it doesn't know about connection because that's internal to the extension binary's Cobra tree.

The extension binary never receives ["connection", "list"] as args because azd doesn't route past the group node.

What we need from the core framework

A way for azure.ai.agents with namespace: ai to coexist with other ai.* extensions:

  • azd ai connection list → routed to azure.ai.agents binary with args ["connection", "list"]
  • azd ai agent init → routed to azure.ai.agents binary with args ["agent", "init"]
  • azd ai models ... → still routed to azure.ai.models binary

This likely requires either:

  1. Relaxing the prefix conflict check for the "parent owns the namespace" case
  2. Changing how bindExtension dispatches — when an extension owns ai, unknown subcommands under ai should forward to that extension's binary instead of showing the group help

Files changed

  • extension.yaml — namespace ai.agentai
  • main.go — imports internal.NewRootCommand() (top-level root)
  • internal/root.go — NEW: wires agent + connection as siblings
  • internal/cmd/root.go — renamed to NewAgentRootCommand, returns subcommand group
  • internal/cmd/debug.go — exported SetupDebugLogging for root.go
  • internal/connections/ — NEW: self-contained connection commands (cmd, pkg, exterrors)
  • internal/cmd/connection_credentials.go — NEW: credential reference resolution for run
  • internal/cmd/run.go — resolves ${{connections...}} patterns at agent startup

Naman Tyagi and others added 2 commits May 13, 2026 19:48
Add connection CRUD commands as a sibling subcommand group under azd ai:
- azd ai connection list (ARM with server-side category filter)
- azd ai connection show (ARM metadata + optional data-plane credentials)
- azd ai connection create (ARM PUT with --force upsert, pre-check GET)
- azd ai connection delete (ARM DELETE with confirmation prompt)

Architecture:
- Extension namespace changed from ai.agent to ai
- Connection code in internal/connections/ (self-contained, no agent imports)
- Hybrid API: ARM SDK for CRUD, data-plane for credential fetch
- 5-level project endpoint resolution cascade
- ARM context discovery via data-plane bootstrap GET
- Credential reference strings in show output for agent.yaml

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
During local agent startup, scan the agent manifest environment_variables
for connection reference patterns, fetch credentials from the Foundry
data plane via POST getConnectionWithCredentials, and inject resolved
values into the spawned agent process environment.

- Reads agent.manifest.yaml / agent.yaml from the project directory
- Matches pattern and resolves via data-plane API
- Caches per connection name to avoid redundant API calls
- Logs key names only, never credential values
- Fails gracefully with a warning if resolution fails

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
@JeffreyCA JeffreyCA added the ext-agents azure.ai.{agents,connections,inspector,projects,routines,skills,toolboxes} extensions label May 20, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

ext-agents azure.ai.{agents,connections,inspector,projects,routines,skills,toolboxes} extensions

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants