Sideloading Teams apps suddenly blocked? YES it's broken.

This article explains why you might have some trouble uploading your custom Teams app on your dev tenant lately. Because, yes - there's an ongoing service disruption going on.

Problem

For some background, my tenants have sideloading (uploading custom Teams apps) enabled:

But when you're trying to Upload an app, it'll tell you sideloading is disabled anyway (that's what "Request approval from your IT admin to be able to upload apps." means)

A small oddity is that if you make your screen more narrow, it becomes enabled... But it won't work.

It'll just open an empty pop-up for uploading your app.

It's a pretty nice touch, really. Underlines the polishing done on the whole experience really prettily.

Anyway - in the browser console, you'll see the following beautiful error:

The actual error will look somewhat like below:

{
    "context": "DataLayerClient",
    "subContext": "getCustomAppPolicy",
    "code": "RemoteOperationFailed",
    "isExpected": false,
    "name": "CustomAppPolicySyncJob",
    "message": "{\"name\":\"Error\",\"message\":\"TransformFailed\",\"stack\":[],\"reason\":\"TransformFailed\",\"serverResponse\":{\"status\":200,\"headers\":{\"access-control-expose-headers\":\"X-ServerRequestId\",\"cache-control\":\"no-cache, no-store\",\"content-encoding\":\"gzip\",\"content-type\":\"application/json; charset=utf-8\",\"date\":\"Sat, 12 Jul 2025 18:58:35 GMT\",\"strict-transport-security\":\"max-age=31536000; includeSubDomains\",\"vary\":\"Accept-Encoding\",\"x-cache\":\"CONFIG_NOCACHE\",\"x-envoy-upstream-service-time\":\"74\",\"x-machinename\":\"mtsvc000009\",\"x-msedge-ref\":\"Ref A: 23B50027B30A42189F7953E51A04FFA0 Ref B: HEL02EDGE0309 Ref C: 2025-07-12T18:58:36Z\",\"x-request-id\":\"ee3ebe88-b589-4f51-afe8-5abcc8b3c698\",\"x-serverrequestid\":\"23B50027B30A42189F7953E51A04FFA0\"},\"body\":{},\"url\":\"https://teams.microsoft.com/api/mt/emea/beta/me/settings/canManageLobApps\"},\"innerException\":{\"name\":\"Error\",\"message\":\"TransformFailed\",\"stack\":[],\"reason\":\"TransformFailed\"}}",
    "originalErrorMessage": "TransformFailed",
    "originalErrorReason": "TransformFailed",
    "statusCode": {
        "status": 200,
        "headers": {
            "access-control-expose-headers": "X-ServerRequestId",
            "cache-control": "no-cache, no-store",
            "content-encoding": "gzip",
            "content-type": "application/json; charset=utf-8",
            "date": "Sat, 12 Jul 2025 18:58:35 GMT",
            "strict-transport-security": "max-age=31536000; includeSubDomains",
            "vary": "Accept-Encoding",
            "x-cache": "CONFIG_NOCACHE",
            "x-envoy-upstream-service-time": "74",
            "x-machinename": "mtsvc000009",
            "x-msedge-ref": "Ref A: 23B50027B30A42189F7953E51A04FFA0 Ref B: HEL02EDGE0309 Ref C: 2025-07-12T18:58:36Z",
            "x-request-id": "ee3ebe88-b589-4f51-afe8-5abcc8b3c698",
            "x-serverrequestid": "23B50027B30A42189F7953E51A04FFA0"
        },
        "body": {},
        "url": "https://teams.microsoft.com/api/mt/emea/beta/me/settings/canManageLobApps"
    }
}

"CustomAppPolicySyncJob"... Hmm. I DID try creating a new custom policy for app installations, but it didn't actually make any difference.

Turning policies off and on again didn't make a difference, either.

Another oddity is the Microsoft 365 Agents Toolkit - it will happily say you're good to go.

But deployments will (after a very long while) fail.

What gives?

Reason

It's not you, it's Microsoft.

This GitHub discussion describes it neatly:

https://github.com/OfficeDev/microsoft-365-agents-toolkit/issues/14193

So essentially, someone in an "upstream team" made an oopsie, and fixing it will take a while.

Solution

There's no solution. Microsoft is fixing it, eventually.

I have a support ticket open for this, and will update this article if Microsoft comes back with an ETA. They probably won't, though.

On the GitHub ticket Microsoft said something this:

The fix has been merged but it will roll out to R3 on 07/10, R4 on 07/21 as mentioned by service team.

"R3" and "R4" being "Ring 3" and "Ring 4" for Microsoft's internal releases - and like user HuihuiWu says in the next comment, it might take some time before any of this reaches the customer release rings.

It's internal channels of Teams client. It may takes time before rolling out to official release.

Just to expand on the release rings a little bit - below is from Microsoft on the release rings terminology:

The red arrows are mine. We're currently in the internal release rings.

When will it be fixed?

Well, Microsoft is testing a fix internally. If it goes well, it'll take them from a few weeks to some months to fix it - IF they ever will fix it.

Sometimes Microsoft chooses not to - but this of course impacts the very core of their Microsoft 365 Copilot extensibility story, so I'd hope they make sure to stabilize and ship the fix quickly.

Of course, the situation right now is a bit annoying, if you actually wanted to do something with your dev tenant. You might even be paying for some Copilot licenses for a tenant where you can't develop any agents for it.

So if you want to have an effect on the timeline of this particular fix, perhaps voice your concern on this GitHub issue - in a polite tone, of course. As HuihuiWu mentions, it's an "upstream issue", and the M365 Copilot Extensibility folks can't do much about it (except maybe pressure the upstream teams).