ChatControl builds an invalid API hostname for **default** Power Platform environments

[tecnomaster]

Repo: microsoft/CopilotStudioSamples
Sample: ui/embed/pcf-canvas-app (ChatControl PCF, solution AgentControls)

Summary

ChatControl constructs the Copilot Studio direct-to-engine hostname by splitting the environment ID two characters from the end. That is correct for a 32-character GUID, but a default environment's ID is Default- followed by a GUID — 39 characters — so the split lands seven characters early and produces a hostname that does not exist in DNS.

Every request fails with net::ERR_NAME_NOT_RESOLVED. No conversation is created, no session is recorded on the agent, and the control shows a typing indicator indefinitely. The panel surfaces no error to the user.

Environment

• Power Platform environment: default environment (Default-<tenant GUID>)
• Agent: published, works correctly in the Teams and Microsoft 365 channels
• Web app channel: enabled
• Entra app registration: Single-page application platform, delegated CopilotStudio.Copilots.Invoke, admin consent granted
• Token acquisition: succeeds (fails only if the redirect URIs are registered under the Web platform — separate, expected, AADSTS9002326)

Repro

1. Use a tenant's default Power Platform environment.
2. Create and publish a Copilot Studio agent in it. Enable the Web app channel.
3. Configure ChatControl with environmentId set to the value shown in Copilot Studio → Settings → Advanced → Metadata, i.e. Default-<tenant GUID>.
4. Open the app and start a conversation.

Expected

The control calls the host published by Copilot Studio → Channels → Web app:

https://default5e04a99d91a64ede9f8be6cdea7e2f.9d.environment.api.powerplatform.com/
    copilotstudio/dataverse-backed/authenticated/bots/<schemaName>/conversations?api-version=2022-03-01-preview

Actual

The control calls a host with the label boundary seven characters too early:

https://default5e04a99d91a64ede9f8be6c.dea7e2f9d.environment.api.powerplatform.com/
    copilotstudio/dataverse-backed/authenticated/bots/<schemaName>/conversations?api-version=2022-03-01-preview

Side by side:

expected: default5e04a99d91a64ede9f8be6cdea7e2f . 9d      (37 + 2)
actual:   default5e04a99d91a64ede9f8be6c        . dea7e2f9d (30 + 9)

Network tab shows repeated (failed) net::ERR_NAME_NOT_RESOLVED on conversations?api-version=2022-03-01-preview, including the CORS preflight.

Verification that this is a hostname bug and not DNS or configuration

• The expected host resolves and responds:
  GET https://default5e04a99d91a64ede9f8be6cdea7e2f.9d.environment.api.powerplatform.com/ →
  {"code":"RouteNotFound","message":"The request URI ... does not match any known API routes."}
• The actual host does not resolve: DNS_PROBE_FINISHED_NXDOMAIN.
• Passing the bare GUID instead of the Default--prefixed ID does not help: the resulting host 5e04a99d91a64ede9f8be6cdea7e2f.9d.environment.api.powerplatform.com also returns NXDOMAIN, because the default prefix is part of the real hostname.

There is therefore no value of environmentId that yields a working host on a default environment.

Suggested fix

Derive the hostname from the environment ID by taking the last two characters as the trailing DNS label after removing hyphens and lowercasing, rather than assuming a fixed 32-character length:

const id = environmentId.replace(/-/g, '').toLowerCase();
const host = `${id.slice(0, -2)}.${id.slice(-2)}.environment.api.powerplatform.com`;

This produces the correct host for both Default-<guid> and plain-GUID environment IDs.

Alternatively, accept the full connection string from Copilot Studio → Channels → Web app as a control property, which removes the need to reconstruct the hostname at all.

Impact

Any tenant whose agent lives in the default environment — the common case for organisations that have never created additional environments — cannot use this control at all, and the failure mode gives no actionable error.