Copilot sdk silently fails with I'm sorry, but I cannot assist with that request using azure

[ajasingh]

Hi i have configured azure 5.5 with copilot now suddently im getting unexplained errors and the request terminates with I'm sorry, but I cannot assist with that request using azure , when i add some logs i get this I'm sorry, but I cannot assist with that request with this debug log
Assistant usage model=gpt-5.5, providerCallId=unavailable, apiCallId=resp_0a7562f68f56df66016a149620af848196a192b9e43a7b749e, inputTokens=0, outputTokens=0, durationMs=1784
[UserTrainingAgent][user-training-agent-inc-INC6311338] Assistant message requestId=unavailable, interactionId=b6989d65-192a-4959-9b02-4437dbf5bd15, outputTokens=0, contentChars=49, contentPreview="I'm sorry, but I cannot assist with that request."
[UserTrainingAgent][user-training-agent-inc-INC6311338] Session completed toolCalls=1, observedEvents={pending_messages.modified=2, hook.start=5, hook.end=5, session.skills_loaded=1, system.message=1, session.tools_updated=1, user.message=2, assistant.turn_start=2, session.usage_info=2, assistant.usage=2, assistant.message=2, tool.execution_start=1, tool.execution_complete=1, skill.invoked=1, assistant.turn_end=2, assistant.reasoning=1, session.idle=1}, persistedMessages=23, finalContentChars=49

im basically stuck at this and unable to figure out why input tokens =0 and outputtokens =0 is coming anybody faced this issue before ?

[github-actions]

Investigation Findings

Thanks for the detailed debug log. After reviewing this, this is not a bug in the copilot-sdk — the SDK is behaving correctly. Here's what's happening:

What the log tells us

The response "I'm sorry, but I cannot assist with that request." with inputTokens=0, outputTokens=0 is a content policy refusal from the Azure OpenAI model (gpt-5.5), not an SDK error. When Azure OpenAI's content filter triggers before processing the prompt (e.g., due to prompt content, topic restrictions, or Azure policy configuration), it can return a refusal response with zero token counts — the request never reaches the model's token-processing stage.

Root cause

This is typically caused by one or more of the following:

1. Azure content filtering — your Azure OpenAI deployment may have content filters enabled that are blocking the request topic/content.
2. Model policy — gpt-5.5 on Azure may have restrictions for certain request types.
3. Azure subscription/deployment restrictions — some Azure OpenAI configurations restrict certain use cases at the deployment level.

The SDK correctly received the refusal message from the model and surfaced it as the assistant response — that's the intended behavior.

What to check

• Review the Azure OpenAI content filter settings for your deployment in Azure Portal.
• Check if the request content matches any restricted categories.
• Try the same prompt directly via the Azure OpenAI playground to confirm whether the filter triggers there too (outside of the SDK).
• Look at the Azure OpenAI activity logs for more detail on why the request was filtered.

Reclassifying as question since this is a usage/configuration issue with Azure OpenAI content policy, not a defect in the copilot-sdk.

Generated by Bug Handler for issue #1419 · ● 1.1M · ◷

[ajasingh]

But how can i be sure about that is there a event which gets captured because i do not see any session error or model error event should not it be a exception in case no token is recieved why its not going inside the session failure ?

[roji]

This isn't a failure in the standard sense; even if the prompt technically doesn't reach the model on the server side, you can interpret it as a response to the effect of "I can't/don't know how to answer that". Throwing an exception for this would probably be undesirable for the vast majority of users: it would mean that specific user prompts might generate an exception (rather than a response) based on its contents, which the application would have to catch and handle in a special way.

Implementation-wise it's also unlikely we can actually distinguish between regular messages and "I cannot assist you"; the zero token count in itself may not unambiguously express the fact that an error has occurred.

I'll go ahead and close this as the intended behavior.