Microsoft’s September 25 announcement of Copilot Code gives employees a way to describe an app, dashboard, tracker, automation or workflow in natural language. The harder enterprise question is what happens after an app is built. Copilot Managed Runtime, now in preview, is Microsoft’s answer for running apps made through Cowork, Code, Copilot Studio and third-party or pro-code tools. Its documented controls are substantial, but administrators still have to reconcile different creation defaults, connector access and separate build and runtime charges before treating the preview as a production path.
What Microsoft announced, and what remains a preview
Microsoft says Copilot Code uses the same underlying technology as GitHub Copilot. The company describes a sandbox for building and says the experience can be tenant-hosted. Its announcement places the Frontier rollout at the end of September and wider availability in the following weeks, with Microsoft 365 Premium and Pro previews later in the year. It does not provide an exact general availability date or a US dollar price.
Managed Runtime has a wider scope than that one new creation experience. The Microsoft admin guide covers apps created through several paths and explicitly labels its guidance prerelease and subject to change. That matters when interpreting the launch: a documented preview control is a description of Microsoft’s current design, not evidence that every customer has the same rollout or that every production use case has been proven.
Microsoft lists Entra authentication, more than 1,500 connectors, Git source control, data loss prevention, Conditional Access, sharing limits and connector policies. It also describes centralized inventory, usage, health and lifecycle controls. These are Microsoft’s stated capabilities. For an IT team, they describe where to inspect an app after a maker creates it; the documentation alone does not establish how reliably every authentication and connector combination behaves in a given tenant.
The creation path changes the starting controls
The preview does not begin with one universal switch. Cowork requires Frontier onboarding. The command-line interface is off by default, while Copilot Studio app creation is on by default. Global and Power Platform Administrators manage the CLI and Studio paths, but Power Platform Administrators cannot enable Frontier. Public GitHub repositories and external build artifacts are disabled by default.
Those differences make the app’s origin an operational detail. An administrator reviewing a Code or Cowork request should not assume that a Studio or CLI setting governs it. Conversely, an enabled Studio creation path should not be taken as proof that Frontier onboarding has occurred. The table summarizes Microsoft’s documented preview defaults and the immediate check each one suggests.
| Path or control | Documented preview state | Admin check |
|---|---|---|
| Cowork | Frontier onboarding required | Confirm eligibility and who can enable it |
| CLI | Off by default | Review maker access before enabling |
| Copilot Studio | App creation on by default | Check permissions and connector policies |
| Public GitHub and external artifacts | Disabled by default | Review any proposed exception |
Build costs and runtime costs need separate budgets
Microsoft documents distinct credit policies for building and running apps. Cowork build usage requires a Copilot license and is billed separately. Copilot Studio build usage is billed per environment. The Copilot credits billing overview is a starting point for the billing model, but the research available for this article does not establish a single US dollar price for the new offering.
That separation changes a purchase discussion. A team cannot infer its operating budget solely from the licenses held by app makers, nor can it assume that a successful build accounts for later runtime consumption. Before broader deployment, it should map the chosen creation path to its build policy and set a distinct expectation for runtime credits. This is an editorial implication of Microsoft’s documented split, not a quoted cost estimate or an independent spending test.
Two preview reports show where assurance has limits
Two open issues in Microsoft’s managed-apps repository illustrate possible integration questions without measuring the product as a whole. Both predate the September 25 announcement and concern the Managed Apps preview or its tooling family. Neither tests the newly announced Copilot Code rollout.
In issue #31, opened September 23, Markus Tobler reports that a SharePoint list works locally but fails after deployment as a Managed App when a Conditional Access step-up challenge appears, with error AADSTS50158. He suggests an authentication retry explanation, which has not been verified. At the report’s September 27 check, the issue was open, had no comments or assignee, and had not been updated since opening. This is one reported tenant and reproduction, not evidence of a general Conditional Access failure.
In issue #29, opened September 10, Carlos reports a Dataverse connector alias ambiguity and an App Player CRUD OperationNotFound error on CLI 0.23.0, Windows and Node 26.7.0. The reporter posted one follow-up comment five minutes later. At the same research check, the issue remained open, with no assignee or visible maintainer response. The author’s workaround has not been independently validated. The two issues describe different symptoms and do not establish a common cause or prevalence.
Microsoft’s documented identity and policy controls are meaningful: they give administrators mechanisms to apply existing governance to apps made through several tools. These individual reports leave a narrower question open about particular connector and authentication paths in the preview. They neither invalidate the stated controls nor confirm production reliability across tenants.
What administrators should verify next
For a US organization considering the preview, the practical sequence is to identify the intended creation path, confirm its default and eligible administrators, review maker permissions and connector or artifact policies, then budget build and runtime credits separately. The answers may vary with tenant and plan rollout. Exact general availability timing, US dollar pricing, support terms and production reliability remain unspecified in the materials used here.
The promise is a shorter route from natural-language request to governed app. The decision still rests on the configuration an organization actually receives and the workload it intends to run. Microsoft’s published guide describes the guardrails; the preview gives administrators reason to inspect those guardrails in their own path before expanding use.