Azure OpenAI isn't supported by Agentic Workflows.

[jsalmassy]

I've been trying to get Azure OpenAI to work for awhile now. I'm using copilot's cli to configure the agentic workflow and have had no success getting it to work. Either 1) Agentic Workflows doesn't support Azure OpenAI 2) There is a specific configuration in Azure OpenAI that isn't documented or 3) Copilot's agentic-workflow agent does not understand how to do this configuration.

Here is a summary of the output from the debug I ran on this last session representing 5 failed runs.

PR Coding Standards Review Workflow — BYOK Azure OpenAI Debugging Summary

Repo: redacted
Branch: redacted/701202-opanai
Workflow: .github/workflows/pr-coding-standards-review.md
Goal: Run the Copilot CLI engine through a BYOK Azure OpenAI deployment instead of GitHub's default model routing.

---

Azure Resource Facts

• Resource: redacted
• Endpoint: https://redacted.openai.azure.com/
• Deployments: gpt-5.4 (original) and gpt-5.4-2026-03-05 (created during debugging)
• Secret: AZURE_OPENAI_API_KEY (confirmed valid)

---

Run 1 — Authentication failure

• Error: HTTP 401 from the API proxy
• Root cause: COPILOT_PROVIDER_API_KEY was declared under secrets: in the frontmatter, which the compiler ignores for credential injection — the key never reached the proxy sidecar.
• Fix: Moved all BYOK credentials into engine.env. Required upgrading the compiler from v0.81.6 → v0.82.0 (pre-release) since engine.env wasn't supported in the older version.

---

Run 2 — Model not found (first occurrence)

• Error: Model 'gpt-5.4' not found on provider at http://172.30.0.30:10002/ (HTTP 404)
• Authentication: Working ✅
• Root cause: Unknown at the time. Hypothesis was the /openai/v1 path lacked broad model support.
• Fix attempted: Changed COPILOT_PROVIDER_BASE_URL to .../openai/v1-preview.

---

Run 3 — v1-preview path doesn't exist

• Error: Same "model not found" but with a clearer smoking gun: the models probe GET .../openai/v1-preview/models returned 404 — the entire /v1-preview path segment doesn't exist on this resource.
• Fix: Reverted COPILOT_PROVIDER_BASE_URL back to .../openai/v1. Confirmed via curl that /openai/v1/models returns HTTP 200 with 164 models.

---

Curl diagnostic findings

Through direct curl tests against the Azure endpoint:

┌─────────────────────────────────────────────────────────────────────┬──────────────────────────────────────────┐
│ Test │ Result │
├─────────────────────────────────────────────────────────────────────┼──────────────────────────────────────────┤
│ GET /openai/v1/models │ ✅ 200 — returns 164 models │
├─────────────────────────────────────────────────────────────────────┼──────────────────────────────────────────┤
│ POST /openai/v1/chat/completions with model: gpt-5.4 │ ✅ Works — gpt-5.4 deployment responds │
├─────────────────────────────────────────────────────────────────────┼──────────────────────────────────────────┤
│ POST /openai/v1/chat/completions with model: gpt-5.4-2026-03-05 │ ✅ Works after new deployment created │
├─────────────────────────────────────────────────────────────────────┼──────────────────────────────────────────┤
│ POST /openai/v1/responses (Responses API) │ ✅ Endpoint exists and responds │
└─────────────────────────────────────────────────────────────────────┴──────────────────────────────────────────┘

Key finding: gpt-5.4 is a deployment name but is NOT in the /openai/v1/models list. The actual model ID in the list is gpt-5.4-2026-03-05. A second Azure deployment named gpt-5.4-2026-03-05 was created to match.

---

Runs 4 & 5 — Proxy routing failure (current blocker)

• Error: Model 'gpt-5.4-2026-03-05' not found on provider at http://172.30.0.30:10002/ (HTTP 404)
• Key observation: The awf-reflect process successfully fetches 164 models from the proxy (http://api-proxy:10002/openai/v1/models). The failure is not a models-list validation error — it happens when the Copilot CLI makes the actual inference call through the AWF API proxy sidecar (http://172.30.0.30:10002/).
• Direct Azure calls work fine — the proxy itself is the blocker, not Azure.
• Last fix attempted: Changed engine.model to openai/gpt-5.4-2026-03-05 (provider-prefixed) based on the theory that the AWF proxy's model routing rules require provider/model namespaced names (e.g. openai/gpt-5.4*, copilot/gpt-5.4*). This also did not resolve the issue.

---

Current state of engine: frontmatter

engine:
id: copilot
model: openai/gpt-5.4-2026-03-05
env:
COPILOT_PROVIDER_BASE_URL: https://redacted.openai.azure.com/openai/v1
COPILOT_PROVIDER_API_KEY: ${{ secrets.AZURE_OPENAI_API_KEY }}
COPILOT_PROVIDER_WIRE_API: responses

---

Outstanding question for GitHub SA

The AWF API proxy sidecar (http://172.30.0.30:10002/) consistently returns HTTP 404 "model not found" for both gpt-5.4 and gpt-5.4-2026-03-05 when in BYOK mode pointing at Azure Foundry (/openai/v1). Direct calls to the Azure endpoint with the same model names succeed.

The core question: In BYOK mode with COPILOT_PROVIDER_BASE_URL pointing to Azure Foundry (/openai/v1), what exact format does COPILOT_MODEL / engine.model need to be in for the AWF API proxy to accept and correctly route the inference request to the provider?

[pelikhan]

/scout research azure openai support (see smoke azure workflows + docs). answer requertss.

[github-actions]

🔭 Recon complete! Scout has charted the territory. Map ready! 🗺️

[github-actions]

🔍 Scout Research Report

Triggered by @pelikhan — "research azure openai support (see smoke azure workflows + docs)"

Executive Summary

Azure OpenAI is supported by Agentic Workflows via the Copilot BYOK path — it's documented and covered by two green smoke tests (smoke-copilot-aoai-apikey, smoke-copilot-aoai-entra) plus a raw-connectivity check (aoai-endpoint-smoke-test). The reporter's own diagnosis is basically correct: the AWF API-proxy sidecar is 404-ing before it ever reaches Azure. The cause is two config mistakes in engine.model / model routing, not a missing feature. Fixes below.

Click to expand detailed findings

Root Cause

The proxy fetches the provider's model catalog (GET /openai/v1/models → the 164 models the reporter saw) and validates COPILOT_MODEL against that list before calling Azure. If the name doesn't match a catalog entry exactly, the proxy returns HTTP 404 "model not found" from 172.30.0.30:10002 — which is precisely the observed failure. Direct curl works because it skips this validation layer.

Their current frontmatter:

engine:
  id: copilot
  model: openai/gpt-5.4-2026-03-05          # ← problem #1
  env:
    COPILOT_PROVIDER_BASE_URL: (resource.openai.azure.com/redacted)
    COPILOT_PROVIDER_API_KEY: ${{ secrets.AZURE_OPENAI_API_KEY }}
    COPILOT_PROVIDER_WIRE_API: responses

Problem #1 — the openai/ prefix. COPILOT_MODEL must be the bare catalog model id, no provider namespace. Docs and both working smoke tests use plain names (o4-mini-aw, gpt-4o). openai/gpt-5.4-2026-03-05 can never match the catalog entry gpt-5.4-2026-03-05, so the proxy 404s. Their run-5 theory that the proxy wants openai/model prefixes was the wrong turn.

Problem #2 — deployment name vs. catalog model id. They already found the key fact: gpt-5.4 is a deployment name; the catalog id is gpt-5.4-2026-03-05. gh-aw has a dedicated knob for exactly this — COPILOT_PROVIDER_MODEL_ID: "Model ID sent on the wire when it differs from COPILOT_MODEL (e.g. an Azure deployment name)." COPILOT_MODEL is what the proxy validates against the catalog; COPILOT_PROVIDER_MODEL_ID is what's sent to Azure. They never set this, so validation and wire model were forced to be identical.

Working reference (from .github/workflows/smoke-copilot-aoai-apikey.md, currently passing)

engine:
  id: copilot
  model: o4-mini-aw                 # bare catalog id, no prefix
  bare: true
  env:
    COPILOT_PROVIDER_BASE_URL: ${{ secrets.FOUNDRY_OPENAI_ENDPOINT }}  # .../openai/v1
    COPILOT_PROVIDER_API_KEY:  ${{ secrets.FOUNDRY_API_KEY }}
    COPILOT_PROVIDER_WIRE_API: responses     # o-series/GPT-5 need this

The Entra variant is identical minus the API key, plus engine.auth: {type: github-oidc, provider: azure, azure-tenant-id, azure-client-id} and permissions: id-token: write.

Recommended fix (apikey)

engine:
  id: copilot
  model: gpt-5.4-2026-03-05          # ← bare catalog id from /openai/v1/models (NO openai/ prefix)
  env:
    COPILOT_PROVIDER_BASE_URL: (resource.openai.azure.com/redacted)
    COPILOT_PROVIDER_API_KEY: ${{ secrets.AZURE_OPENAI_API_KEY }}
    COPILOT_PROVIDER_WIRE_API: responses
    COPILOT_PROVIDER_MODEL_ID: gpt-5.4     # ← Azure *deployment* name, if it differs from the catalog id
    # COPILOT_PROVIDER_TYPE: azure         # optional; default openai works for the /openai/v1 style
network:
  allowed:
    - defaults
    - RESOURCE.openai.azure.com            # required: BASE_URL comes from a secret, so add host explicitly

Recommendations

• Drop the openai/ prefix — set engine.model (→ COPILOT_MODEL) to the exact id returned by GET /openai/v1/models.
• Use COPILOT_PROVIDER_MODEL_ID for the Azure deployment name when it differs from the catalog id — that's the documented answer to their "outstanding question for GitHub SA."
• Keep COPILOT_PROVIDER_WIRE_API: responses (correct for GPT-5/o-series; completions gives HTTP 400).
• Since BASE_URL is a secret (not a literal), the host must be added to network.allowed so the threat-detection step can reach it — confirm this is present.
• Their v0.82.0 upgrade for engine.env support was the right call; keep it.
• bare: true (used by the smoke tests) only disables context loading — it is not a proxy fix; the two changes above are.

Key Sources

• docs/src/content/docs/reference/engines.md §"Copilot BYOK Mode" / "Azure Foundry OpenAI" (lines 180–260) — the COPILOT_PROVIDER_MODEL_ID table entry is the crux
• .github/workflows/smoke-copilot-aoai-apikey.md and smoke-copilot-aoai-entra.md — passing end-to-end references
• .github/workflows/aoai-endpoint-smoke-test.yml — raw curl connectivity (OIDC + apikey)

Suggested Next Steps

1. Have the reporter set model: gpt-5.4-2026-03-05 (no prefix) + COPILOT_PROVIDER_MODEL_ID: gpt-5.4 and re-run.
2. If it still 404s, confirm the exact string from their own /openai/v1/models probe is what's in COPILOT_MODEL character-for-character.
3. Consider a docs note explicitly calling out the "deployment name ≠ catalog model id" gotcha next to COPILOT_PROVIDER_MODEL_ID, since this is the second BYOK-Azure report to hit it.

🔭 Intelligence gathered by Scout · 84.3 AIC · ⌖ 13.4 AIC · ⊞ 6.4K · ◷
_{Comment /scout to run again}

[pelikhan]

@copilot update documentation with dedicated section on Azure BOYK