Force application of authorization header can break extensions that require their own authorization header.

In chat-api-dynamic-extensions.ts there is the following code.

// we need to add the user id to the headers as this is expected by the function and does not have context of the user
headerItems.push({
  id: "authorization",
  key: "authorization",
  value: await userHashedId(),
});

In my use case I am connecting to the Azure DevOps API. The API requires an 'Authorization' header with a personal access token issued by DevOps.

The current logic would apply two headers (authorization + Authorization) which breaks the api call.

Recommend we look at refactoring the requirement for that forced authorization header to help support more api call scenarios.

Thanks again for the great repo!

Start in src/features/chat-page/chat-services/chat-api/chat-api-dynamic-extensions.ts, especially where the authorization header is pushed into headerItems. Trace how extension headers are assembled and compare that behavior with the Azure DevOps personal access token use case. Done means extensions can supply their required authorization header without the forced user header breaking the API call.