Copilot Studio Agent in Teams stuck after "Request body too large" error

JEHANNO Malo 0 Reputation points
2026-10-06T07:25:06.19+00:00

image

Hello,

I am experiencing an issue with a Copilot Studio agent deployed in Microsoft Teams.

Context

I uploaded a PDF document of approximately 7.7 MB (7751 KB) containing a large number of images to the agent through a Teams chat.

The agent immediately returned the following error:

OpenAI request failed with response code BadRequest.

Message: Request body too large.

The max request body size is 30000000 bytes.

Error code: ContextTokenLimitExceeded

Unexpected behavior

Since this error occurred, the Teams conversation appears to be permanently broken.

Even if I send a simple message such as:

hello

the agent immediately returns the exact same error.

The issue persists even after:

  • Deleting the conversation history from Teams
  • Closing and reopening Teams
  • Sending completely unrelated messages
  • Waiting several days before trying again

Additional observations

What I find surprising is that the uploaded PDF was only 7.7 MB, while the error mentions a maximum request body size of 30,000,000 bytes (~30 MB).

This makes me wonder whether the issue is not the original file size itself, but rather the size of the context generated after processing the PDF (OCR, image extraction, conversation memory, attachment metadata, etc.).

It looks as if the Teams conversation may have become stuck with an oversized context that continues to be reused for every subsequent message.

Important detail

The Copilot Studio agent works perfectly when accessed through the Microsoft Copilot app.

The problem only occurs when using the same agent through Microsoft Teams.

This suggests there may be a difference in how conversation state or session memory is managed between Teams and the Copilot application.

Questions

  1. Is this a known issue with Copilot Studio agents in Teams?
  2. Does "Delete conversation history" actually clear the conversation/session state used by the agent?
  3. Is there a way to force a complete reset of the conversation memory for a Teams conversation?
  4. Could a failed PDF processing operation leave the Teams conversation in a corrupted state?
  5. Why would the issue persist in Teams while the same agent works correctly in the Copilot app?

Any guidance would be greatly appreciated.

Thank you.

Microsoft Copilot | Microsoft 365 Copilot | Development
0 comments No comments

3 answers

Sort by: Newest
  1. Prasad-MSFT 10,546 Reputation points Microsoft External Staff Moderator
    2026-10-06T12:28:42.75+00:00

    The important distinction is between the size of the uploaded PDF and the size of the request ultimately sent to the model. A 7.7 MB PDF can potentially generate a much larger amount of contextual data after processing, particularly when the document contains many images and requires OCR/content extraction. The resulting request may include extracted text, image-related content, attachment metadata, conversation history, and other agent context. Therefore, the 30,000,000 bytes limit in the error should not be interpreted as a 30 MB limit on the original PDF itself. It is a limit on the request body being sent to the OpenAI/model endpoint.

    The more interesting part of your case is that even hello fails after the PDF upload. If the problem were simply that the PDF itself exceeded a file-upload limit, you would normally expect the subsequent hello message to work. The fact that unrelated messages continue to produce:

    Request body too large ContextTokenLimitExceeded

    suggests that some of the conversation/session context created by the attachment may still be included when processing subsequent messages.

    This is particularly relevant to Teams because Teams supports persistent conversations. In Copilot Studio, resetting the conversation and clearing the conversation history are not necessarily the same thing. The normal reset behavior can reset variables/state without necessarily removing all conversation history that is being supplied to the planner/model.

    The fact that the same agent works correctly in the Microsoft Copilot app but fails in Teams is another strong indication that the agent itself is probably not fundamentally broken. It points more toward a difference in how the Teams channel is maintaining or reconstructing the conversation/session context.

    Test this in the following order:

    1. In the affected Teams conversation, send start over and then send hello.
    2. If it still fails, create a completely new Teams conversation/chat with the same agent.
    3. Send hello in the new conversation before uploading any file.
    4. If that works, try a small PDF first and then the original PDF.
    5. If even a brand-new Teams conversation fails with hello, while the same agent continues to work in Microsoft Copilot, this will be considered as a strong evidence of a Teams/Copilot Studio service-side or session-state issue.

    Was this answer helpful?

    0 comments No comments

  2. JEHANNO Malo 0 Reputation points
    2026-10-06T07:39:41.03+00:00

    Thank you for the detailed explanation.

    However, the documented recovery actions do not resolve the issue in my case.

    Additional findings:

    • The agent continues to work correctly in the Microsoft Copilot app.
    • Other users can use the Teams agent without any problem.
    • A colleague reproduced the issue after uploading the same large PDF containing many images. His Teams conversation is now also permanently broken.
    • Users who did not upload the PDF are not affected.

    I have already tested:

    • Deleting conversation history
    • Removing and reinstalling the agent in Teams
    • Republishing the agent
    • Using /foundry_new_preview

    None of these actions changed the behavior.

    What is particularly surprising is that /foundry_new_preview itself returns the same Request body too large error, which suggests the reset command may never actually be executed.

    It appears that once the large PDF is uploaded, the Teams conversation enters a permanently broken state where every subsequent message (even a simple "hello") immediately returns the same error.

    Based on the behavior observed, this does not seem to be an agent configuration issue because:

    • The same agent works correctly in Copilot.
    • Other users can still use the agent.
    • Only conversations that previously received the large PDF become affected.

    Is there any documented way to completely reset or purge the server-side Teams conversation/session associated with a Copilot Studio agent?

    Also, should the conversation ID change after using /foundry_new_preview or after deleting the conversation history? In my case, the conversation appears to remain stuck in the same state.

    This currently looks like a Teams conversation/session corruption issue rather than a normal context limit error.Thank you for the detailed explanation.

    However, the documented recovery actions do not resolve the issue in my case.

    Additional findings:

    • The agent continues to work correctly in the Microsoft Copilot app.
    • Other users can use the Teams agent without any problem.
    • A colleague reproduced the issue after uploading the same large PDF containing many images. His Teams conversation is now also permanently broken.
    • Users who did not upload the PDF are not affected.

    I have already tested:

    • Deleting conversation history
    • Removing and reinstalling the agent in Teams
    • Republishing the agent
    • Using /foundry_new_preview

    None of these actions changed the behavior.

    What is particularly surprising is that /foundry_new_preview itself returns the same Request body too large error, which suggests the reset command may never actually be executed.

    It appears that once the large PDF is uploaded, the Teams conversation enters a permanently broken state where every subsequent message (even a simple "hello") immediately returns the same error.

    Based on the behavior observed, this does not seem to be an agent configuration issue because:

    • The same agent works correctly in Copilot.
    • Other users can still use the agent.
    • Only conversations that previously received the large PDF become affected.

    Is there any documented way to completely reset or purge the server-side Teams conversation/session associated with a Copilot Studio agent?

    Also, should the conversation ID change after using /foundry_new_preview or after deleting the conversation history? In my case, the conversation appears to remain stuck in the same state.

    This currently looks like a Teams conversation/session corruption issue rather than a normal context limit error.

    Was this answer helpful?

    0 comments No comments

  3. AI answer

    2026-10-06T07:25:34.7933333+00:00

    Yes, this aligns with documented behavior around oversized conversation context and stuck sessions.

    1. Is this a known issue in Teams?
      A request can fail when the prompt, conversation history, or attachments exceed the model’s context window. When several large files are involved, or when accumulated conversation content becomes too large, the agent can stop responding or return errors. In Teams, there is also a documented case where a session can appear stuck and requires a new conversation.
    2. Does deleting Teams conversation history clear the agent session state?
      The available documentation does not state that deleting Teams chat history clears the agent runtime session. What is documented is that, in Teams, resetting the conversation requires sending a specific command. Deleting chat history is not documented as the reset mechanism.
    3. How to force a complete reset in Teams
      Use the documented Teams reset command:
      1. Open the chat with the agent in Microsoft Teams.
      2. Send /foundry_new_preview.
      3. This resets the conversation and starts a new session.
      Important: the previous conversation cannot be restored after this reset. This is the documented recovery step when a published agent stops responding or returns an error such as no tool output found, and it is the only documented Teams method to start a new session.
    4. Could failed PDF processing leave the Teams conversation in a bad state?
      The documented behavior supports that possibility at the session level: if the combined prompt, conversation history, or uploaded content exceeds processing limits, the agent can fail, and earlier uploaded files continue to count in the same conversation. Large files in one conversation can cause the agent to stop responding or return an error until a new conversation is started.
    5. Why the PDF size and the 30 MB error can both be true
      The uploaded file size is not the only factor. Documented limits are based on processed content as well as accumulated conversation state:
      • Without code interpreter, the agent reads up to 30,000 characters per file and 30,000 characters total across multiple files for extracted text from Office documents. If extracted text exceeds that limit, content can be discarded.
      • Multiple uploaded files, or large content retained in the same conversation, add to the total content the model must process.
      • Earlier uploads continue to count later in the same conversation.
      • A request can fail if the prompt, conversation history, or attachments exceed the model’s context window.
      The documentation does not explain the exact byte calculation behind the 30000000 bytes message for this Teams error, so only the supported conclusion is that processed conversation content can exceed runtime limits even when the original file itself seems smaller.
    6. Why it works in the Copilot app but not in Teams
      The documented material shows different reset behavior by host. In Microsoft Copilot, starting a new chat creates a fresh conversation. In Teams, the documented way to reset is /foundry_new_preview, and Teams does not currently provide another way to start a new session. That difference in session handling explains why one host can continue working while a Teams thread remains stuck.

    If the Teams thread still immediately returns the same error after /foundry_new_preview, the documented self-service path is exhausted. A similar reported case describes this as requiring service-side investigation, especially when the same conversation remains permanently stuck.


    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.