Setting Up Your Dev Environment for Microsoft 365 Copilot Extensibility

Half the time spent on a new Copilot extension project is the developer trying to get their machine into a state where they can ship code. The Microsoft prerequisites page lists what you need, but it doesn't tell you what's painful, what's optional in theory and mandatory in practice, or what you'll trip over the first time you try to deploy.

I've onboarded enough developers onto Copilot extension projects to have opinions about this. So instead of repeating the Microsoft list, here's what actually matters when you're standing up a dev environment in an Australian organisation, including the bits that go wrong when your IT department has locked things down.

The base requirements that are real

You need a Microsoft 365 tenant where you can install custom apps. Sounds obvious. In practice, this is where most projects stall for the first week. If you're working inside an enterprise tenant, the central IT team has almost certainly disabled custom app uploads for everyone except admins. You can't develop a Copilot extension without permission to sideload an app, and that permission isn't granted by default.

Two paths forward. Either get your tenant admin to enable custom app uploads for your developer accounts (faster but might run into governance review), or sign up for a Microsoft 365 developer tenant separate from your work tenant (slower setup but no governance battles).

I usually push clients toward the developer tenant approach for the build phase. The free Microsoft 365 developer subscription gives you a sandbox tenant with everything you need, and you can copy across to production once the extension is reviewed. The tradeoff is that you can't test against real data, which matters more for some use cases than others. For a customer service agent that calls your CRM, you'll want production tenant access at some point. For a public document Q&A agent, the developer tenant is fine end-to-end.

If you're going the developer tenant route, accept that it expires every 90 days unless you keep activity going. Microsoft auto-renews if you've shown active development, but it's caught people out. Lost a tenant once mid-project. Not great.

The right Microsoft 365 Copilot license

The other thing that catches teams out is licensing. To actually test your extension end-to-end against the real Copilot, someone needs a Microsoft 365 Copilot license. Those aren't free. As of writing they're around AUD $50 per user per month, with a 12-month commitment in most enterprise agreements.

For a development team, you don't need every developer licensed. You need at least one person who can validate "does this thing actually appear in Copilot and respond correctly". A common pattern we use - one or two licensed accounts for end-to-end testing, with the rest of the team doing local development and using shared test sessions when needed.

Worth noting that Copilot Studio licensing is separate and works on a message-pack model. That's the thing that catches finance teams off guard at renewal.

What to install locally

The toolchain you actually need:

Visual Studio Code with the Teams Toolkit extension. This is the centre of gravity for Copilot extension development. It handles project scaffolding, app manifest editing, packaging, sideloading, and most of the boring plumbing. Older docs reference the standalone Teams Toolkit for Visual Studio - you can use it if you're already a heavy Visual Studio user, but the VS Code extension gets updates faster.

Node.js LTS. Even if your backend is .NET, Teams Toolkit is built on Node and you'll need it for the scaffolding and packaging steps. Use a version manager (nvm or volta) because Microsoft updates the required Node version periodically without much warning. Don't fight it. Install the version Teams Toolkit asks for.

Your backend stack. .NET 8 or 9 if you're going that route. We do a lot of .NET work for clients because it's the natural choice when the rest of the Microsoft stack is already there. Python or Node also work if your team is stronger there. The OpenAPI spec doesn't care what language is behind it.

The Microsoft 365 Agents Toolkit CLI. This is the command-line version of what the VS Code extension does. You don't strictly need it, but you will eventually want it for CI/CD pipelines. Install it once you start automating deploys.

A way to expose your local API to the public internet. During development, Copilot needs to call your API, and your API is running on localhost. Some kind of tunnel - ngrok, Cloudflare tunnel, or the dev tunnels feature inside Visual Studio - is essential. Teams Toolkit will spin up a dev tunnel automatically if you let it. I usually let it.

That's the actual list. Ignore anyone telling you that you need Azure Functions Core Tools, Bicep CLI, or a dozen other things at the start. You might need them later for deployment. You don't need them to write your first Copilot extension.

The bits that go wrong on Australian corporate machines

A few things specific to Australian enterprise environments that come up repeatedly.

Corporate proxies break npm installs. If your machine sits behind a proxy that does TLS inspection (most banks, insurers, and government departments), npm and the Teams Toolkit will fail in strange ways. The fix is usually to configure npm with the corporate proxy certificate. Your IT team has done this before, ask them for the exact config rather than guessing.

WSL is your friend. A lot of the Teams Toolkit tooling assumes a Unix-style environment. On a corporate Windows machine, WSL 2 with Ubuntu gives you the smoothest path. Install your Node, your dev tools, and run everything inside WSL. Less fighting with Windows path issues and case-sensitivity quirks.

PowerShell execution policy. When the Microsoft tooling tries to run scripts, locked-down execution policies block them. You don't need to disable security org-wide - you can set RemoteSigned for your user account and that's usually enough.

Azure subscription access. Eventually you'll want to deploy your extension's backend somewhere. Most clients deploy to Azure because the integration with Entra ID makes auth easier. Get an Azure subscription provisioned early. The actual provisioning is quick but the procurement approval can take weeks at a large organisation. Start that paperwork on day one of the project.

We help organisations work through this kind of setup as part of our Azure AI consulting work. Half of it is the technology, the other half is navigating internal approvals.

A sensible starter project

Once your environment is set up, don't start with your real use case. Build the sample first. Microsoft's "Declarative Agent" template inside Teams Toolkit is a fine starting point. Scaffold it, sideload it, see it appear in Copilot, send it a message, and watch a response come back. That round trip is what proves your dev environment works.

If you can't get the sample to work end-to-end, your real project is going to fight you the whole way. Stop and fix the environment first. We've had projects where the developer skipped the sample, jumped straight into building the real extension, then spent three days debugging what turned out to be a sideloading permissions issue that the sample would have caught immediately.

The sample is your smoke test. Run it before you write your own code.

What to set up after the basics work

Once you can sideload a sample and have it respond, the next things to set up:

Source control with a sensible branching strategy. Sounds obvious but Copilot extension projects have multiple moving parts - the manifest, the OpenAPI spec, the backend code, the deployment scripts. Decide upfront how these are versioned together. We usually mono-repo it for small projects.

A way to package the manifest for sideloading. Teams Toolkit does this for you, but understanding what's in the package matters when you need to debug why something isn't showing up in Copilot. Crack open the .zip occasionally.

Test data that doesn't depend on real customer info. Even in a developer tenant, get your test data sorted early. Having seven fake customers with realistic data makes the iteration loop much faster. Mock APIs that return sensible data are gold.

A way to capture what Copilot is actually doing. The new agent debugging tools in Teams Toolkit are decent. Use them. The amount of time you can save by seeing exactly which operation Copilot called and what parameters it sent is enormous compared to trying to guess from your API logs.

If you want help getting an Australian team productive on Copilot extensions quickly, we run Copilot implementation engagements that include the environment setup, governance discussions, and first end-to-end extension build. The environment work is the part most teams underestimate. It's worth getting right before you commit serious development time.

Reference: Set up your development environment from the Microsoft 365 Copilot Extensibility documentation.