How to use Coporate Copilot 360 (Europe) ?

[RELAXccc]

Hello,
i have this "free" ai access, but Microslop does not have any harnes available, so i want to use Omniauth as a Proxy

the URL i get

https://m365.cloud.microsoft/chat?auth=2&origindomain=Office&client-request-id=*****&es=SSR&redirfrom=userTypeCookie&redirfrom=cosmicRingCookie

where ***** is an UUID version 4

These are the Cookies.

If there is any other dev, with experience in this repo interested, please respond. Lets develop a plugin together.

Greetings

PS: Yes, i can see those tickets which mention that this should work already. So please tell me how stupid I am and how i can find the correct cookies, i already tried for hours

[diegosouzapw]

Hey @RELAXccc! You are not stupid — you were looking for the wrong kind of credential, and nothing told you that. The provider exists and works.

It is copilot-m365-web (alias m365copilot), defined at src/shared/constants/providers/web-cookie.ts:156-166. The credential is not a cookie. That is why hours of cookie collection got you nowhere: for this provider, cookies are not what authenticates the request.

What you actually need, both parts:

1. Sign in at m365.cloud.microsoft/chat.
2. Open DevTools → Network → filter WS (WebSocket, not XHR/Fetch).
3. Click the Chathub WebSocket connection.
4. From its request URL — wss://…/Chathub/<path>?…&access_token=… — copy both:
   • the access_token query parameter, and
   • the account-specific Chathub path segment.

Both are required. There is no Authorization: Bearer header on any XHR to copy — if that is what you were hunting through, that explains the hours.

Two things that will save you the next round of frustration:

• The token expires in about 75 minutes. If you capture it and it works, then stops working shortly after, that is expected, not a misconfiguration.
• You can avoid re-capturing every 75 minutes. Store a refresh_token in providerSpecificData.refreshToken — from any Microsoft device-code/refresh flow scoped to substrate.office.com/sydney — and OmniRoute pre-flight-refreshes the access token itself.

This is an unofficial integration, so treat it accordingly with a corporate account.

You are right that this should not have required asking: the procedure existed only in the connection form's hint text and nowhere in the docs. Opened #12779 to document it properly, crediting this discussion. Thanks for pushing on it instead of giving up quietly — that is what made the gap visible.

If it still fails after capturing both parts from the WS URL, paste the error (redact the token) and I will trace it.

[RELAXccc]

+1 to the documentation ticket !!.
Copilot is often offered at companies that have a contract with 360, and helpful for coding, but if you are locked out of the new Azure API for copilot (beta) you have NO official way to use any harness, to actually be productive.

This is the first tool i came across which could solve this problem, without trying to reverse engineer my local WebDav Application (which already altered my companies security system once)

Ofc, I will only use this for company purposes, but it still is a amazing fix. Additional Documentation could help other people to find this tool

[RELAXccc]

Thank you very much! this worked perfectly. I only looked at the "How to get the session credential" text within the app.
But now i realize, this info is probably not customized for the Provider.

(Also, it only mentions the chrome cookie-editor plugin, firefox works the same)

The refresh token sounds interesting! Is there any documentation where i could read up on how to implement this?

[RELAXccc]

I will investigate today how to find the token, i just imagine a refresh token is for oauth, so i need any other oauth or single sighn on for MS 360 and spoof all responses?

I also am confused why exactly "substrate.office.com/sydney" sydney as the town or is this some internal codename for MS?

I think, i mentioned (Europe) in the title here, because i was in the impression, they use different services for EU, because they adhere to our laws verry good (thats why companies use them)

[pacocartones]

Great that the WebSocket credential worked. A refresh token is OAuth, but you should not spoof responses or reverse-engineer your company's sign-in flow. It must come from a Microsoft OAuth flow that your tenant and corporate policy permit, requesting offline_access plus the two M365 Chat scopes used by OmniRoute. substrate.office.com/sydney is Microsoft's resource/scope namespace here; “sydney” is an internal service name, not the Australian region, so it does not select where an EU tenant's data is processed. Because this is a corporate account and an unofficial integration, the safe next step is to wait for #12779's documented flow and confirm permission with your administrator rather than copying a refresh token from an unrelated app.

[diegosouzapw]

@RELAXccc — @pacocartones is right on every point, and I want to underline the one that matters most: do not spoof responses or reverse-engineer your company's sign-in flow. This is a corporate tenant and an unofficial integration; the difference between "worked around a login" and "circumvented an access control" is not one you want to argue with your own IT department. Get your administrator's agreement first.

Two factual answers to your specific confusions:

• "sydney" is a Microsoft internal service codename, not the city and not a region selector. substrate.office.com/sydney tells you nothing about where an EU tenant's data is processed. Your instinct that EU tenants might route differently is reasonable, but this string is not the evidence for it.
• The credential is not a refresh token by default. As registered (src/shared/constants/providers/web-cookie.ts:156-166), copilot-m365-web takes the WebSocket access_token plus the Chathub path segment, with roughly a 75-minute lifetime. providerSpecificData.refreshToken is optional and only for a token obtained through a legitimate OAuth flow your tenant permits.

The 75-minute expiry is why this feels unstable rather than broken. #12779 tracks documenting the supported flow properly, which is the path I would wait for rather than assembling one from another app's token.