.NET: [Bug]: TodoProvider injects a synthetic user message between assistant tool_calls and tool results, causing OpenAI 400 invalid_request_error

[soul-soft]

Description

Version

• Microsoft.Agents.AI.Harness: 1.13.0-preview.260703.1
• Microsoft.Agents.AI.OpenAI: 1.13.0

Summary

When using HarnessAgent with the default TodoProvider enabled and an OpenAI chat client underneath, a simple function/tool call can fail with:

HTTP 400 (invalid_request_error: invalid_request_error)
An assistant message with 'tool_calls' must be followed by tool messages responding to each 'tool_call_id'.

The issue appears to be that TodoProvider injects a synthetic user message on every invocation, including the internal continuation call inside the function-invocation loop. That injected user message ends
up between:

• the previous assistant message containing tool_calls
• and the current tool message containing FunctionResultContent

This produces an invalid message sequence for OpenAI.

Minimal repro

var agent = scope.ServiceProvider.GetRequiredService();
var session = await agent.CreateSessionAsync();

AgentResponse response = await agent.RunAsync("获取当前路径", session);

while (true)
{
List approvalRequests = response.Messages
.SelectMany(static x => x.Contents)
.OfType()
.ToList();

  if (approvalRequests.Count == 0)
  {
      break;
  }

  List<ChatMessage> approvalMessages = approvalRequests
      .Select(static request =>
          new ChatMessage(ChatRole.User, [request.CreateResponse(approved: true)]))
      .ToList();

  response = await agent.RunAsync(approvalMessages, session);

}

This also reproduces without approval handling if the first model call returns a tool call and the framework performs the internal follow-up call to send the tool result back to the model.

Observed behavior

If I print the actual messages sent to the underlying OpenAI client, I see two requests.

First request:

[
{
"role": "user",
"contents": [
{
"$type": "text",
"text": "获取当前路径"
}
]
},
{
"role": "user",
"contents": [
{
"$type": "text",
"text": "### Current todo list\n- none yet"
}
],
"additionalProperties": {
"_attribution": {
"sourceType": {
"value": "AIContextProvider"
},
"sourceId": "Microsoft.Agents.AI.TodoProvider"
}
}
}
]

Second request:

[
{
"role": "user",
"contents": [
{
"$type": "text",
"text": "获取当前路径"
}
],
"additionalProperties": {
"_attribution": {
"sourceType": {
"value": "ChatHistory"
},
"sourceId": "Microsoft.Agents.AI.InMemoryChatHistoryProvider"
}
}
},
{
"role": "user",
"contents": [
{
"$type": "text",
"text": "### Current todo list\n- none yet"
}
],
"additionalProperties": {
"_attribution": {
"sourceType": {
"value": "ChatHistory"
},
"sourceId": "Microsoft.Agents.AI.InMemoryChatHistoryProvider"
}
}
},
{
"createdAt": "2026-07-07T10:15:00+00:00",
"role": "assistant",
"contents": [
{
"$type": "text",
"text": ""
},
{
"$type": "reasoning",
"text": "The user is asking "获取当前路径" which means "get the current path/directory". This is a simple question that doesn't require complex steps. Let me just run a shell command to show the
current working directory."
},
{
"$type": "functionCall",
"name": "run_shell",
"arguments": {
"command": "Get-Location | Select-Object -ExpandProperty Path"
},
"informationalOnly": true,
"callId": "call_00_qwP1EnxwrANWfcXYyKvn8275"
}
],
"messageId": "8972ba95-fa5a-43ae-8621-0cc301402483",
"additionalProperties": {
"_attribution": {
"sourceType": {
"value": "ChatHistory"
},
"sourceId": "Microsoft.Agents.AI.InMemoryChatHistoryProvider"
}
}
},
{
"role": "user",
"contents": [
{
"$type": "text",
"text": "### Current todo list\n- none yet"
}
],
"additionalProperties": {
"_attribution": {
"sourceType": {
"value": "AIContextProvider"
},
"sourceId": "Microsoft.Agents.AI.TodoProvider"
}
}
},
{
"role": "tool",
"contents": [
{
"$type": "functionResult",
"result": "C:\Users\DELL\.deepseek\r\nexit_code: 0",
"callId": "call_00_qwP1EnxwrANWfcXYyKvn8275"
}
]
}
]

OpenAI rejects this because the assistant tool call is followed by a synthetic user message before the matching tool result.

Exception

System.ClientModel.ClientResultException: HTTP 400 (invalid_request_error: invalid_request_error)

An assistant message with 'tool_calls' must be followed by tool messages responding to each 'tool_call_id'. (insufficient tool messages following tool_calls message)

Why I think this is a framework bug

The behavior seems to come from the interaction of these pieces:

• TodoProvider injects a synthetic user message on every InvokingAsync
• ChatClientAgent invokes AIContextProviders on every invocation, including internal function-calling continuations
• ChatHistoryProvider persists the first round’s synthetic todo message and assistant function call
• on the second internal call, chat history is loaded, then TodoProvider injects another synthetic user message, then the tool result is appended

This creates the invalid sequence:

assistant(tool_call)
user(todo)
tool(function_result)

Expected behavior

One of the following should happen:

1. TodoProvider should not inject synthetic user messages during internal function-calling continuation calls.
2. More generally, AIContextProvider-injected messages should not be inserted between an assistant message with tool calls and its matching tool results.
3. Alternatively, TodoProvider could provide this state via instructions instead of a synthetic user message in these continuation scenarios.

Workaround

Disabling TodoProvider avoids the issue.

Question

Is this the intended behavior for TodoProvider during internal function-invocation loop iterations, or should providers like this be suppressed for continuation/tool-result turns?

Code Sample

Error Messages / Stack Traces

Package Versions

Microsoft.Agents.AI.OpenAI: 1.13.0 Microsoft.Agents.AI.Harness: 1.13.0-preview.260703.1

.NET Version

.net 10

Additional Context

No response

[github-actions]

👋 Hi 1448376744 (@soul-soft) — thanks for the report!

Your detailed observations including attribution data (sourceType: AIContextProvider, sourceId: Microsoft.Agents.AI.TodoProvider) on the injected message in the second request are very helpful. We wrote tests that replicate the HarnessAgent pipeline (FICC→MessageInj→PerServiceCall with TodoProvider in AIContextProviders and RequirePerServiceCallChatHistoryPersistence=true) and confirmed the non-streaming non-approval path produces valid message ordering — the tool result immediately follows the assistant tool_call. To narrow down the trigger, could you confirm whether this specifically requires the ToolApprovalAgent approval loop (multiple RunAsync calls), or if it truly reproduces on the very first single RunAsync with a simple auto-invoked tool? Also, are you using RunAsync or RunStreamingAsync? If possible, sharing the exact HarnessAgentOptions configuration (especially MaxContextWindowTokens/MaxOutputTokens which enable CompactionProvider) would help us reproduce more precisely.

Once you can share the details above, we'll take another look. 🙏

[soul-soft]

TodoProvider Approval Repro Response

You can reply with the following:

Thanks, this helps narrow it down.

In my repro, this appears to require the ToolApprovalAgent approval loop. I am not seeing it on the first simple single-run synchronous auto-tool path.

More specifically:

- I am using `RunAsync`, not `RunStreamingAsync`.
- It reproduces in a two-step synchronous flow:
  1. `await agent.RunAsync("获取当前路径", session)` returns a `ToolApprovalRequestContent`.
  2. I approve it and call `await agent.RunAsync(new ChatMessage(ChatRole.User, approvalResponses), session)`.

The failure happens inside step 2, after the approved tool is executed and the framework prepares the follow-up model request. At that point, the message sequence sent to the model is effectively:

1. original user message (from chat history)
2. todo message (from chat history)
3. assistant message with `tool_call` (from chat history)
4. a newly injected TodoProvider `user` message
5. `tool` result

So the injected TodoProvider message lands between the assistant `tool_call` and the corresponding `tool` result, which causes the OpenAI validation error.

Additional repro details:

- `RunAsync`, non-streaming
- Approval path required; I do need the ToolApprovalAgent round-trip
- A single approval/resume is enough; I do not need multiple approval cycles
- I did not set `MaxContextWindowTokens` or `MaxOutputTokens`
- I did not configure a custom compaction strategy
- So compaction should be out of the picture in this repro
- I also reproduced it with the default `InMemoryChatHistoryProvider`, so this is not specific to a custom file-based chat history provider

Minimal repro shape:

​```csharp
var agent = scope.ServiceProvider.GetRequiredService<AIAgent>();
var session = await agent.CreateSessionAsync();

var response = await agent.RunAsync("获取当前路径", session);

while (true)
{
    var approvalRequests = response.Messages
        .SelectMany(m => m.Contents)
        .OfType<ToolApprovalRequestContent>()
        .ToList();

    if (approvalRequests.Count == 0)
    {
        break;
    }

    var approvalResponses = approvalRequests
        .Select(r => (AIContent)r.CreateResponse(true))
        .ToList();

    response = await agent.RunAsync(
        new ChatMessage(ChatRole.User, approvalResponses),
        session);
}

The relevant HarnessAgentOptions in my hosting setup are:

new HarnessAgentOptions
{
    FileAccessStore = new FileSystemAgentFileStore(ApplicationRuntimePaths.CurrentDirectoryPath),
    AgentSkillsSource = new AgentFileSkillsSource(
        ApplicationRuntimePaths.SkillsDirectoryPath,
        scriptRunner: skillScriptRunner.RunAsync),
    DisableTodoProvider = false,
    ChatHistoryProvider = new FileChatHistoryProvider(
        new FileSystemAgentFileStore(ApplicationRuntimePaths.SessionsDirectoryPath)),
    ShellExecutor = new LocalShellExecutor(new LocalShellExecutorOptions
    {
        Mode = ShellMode.Persistent,
        ConfineWorkingDirectory = true,
        Timeout = LocalShellExecutor.DefaultTimeout,
        WorkingDirectory = ApplicationRuntimePaths.CurrentDirectoryPath,
    }),
}

I also reproduced the same behavior with a more minimal setup where TodoProvider is enabled and the default InMemoryChatHistoryProvider is used, so the essential conditions seem to be:

• TodoProvider enabled
• per-service-call chat history persistence in the HarnessAgent pipeline
• ToolApprovalAgent approval/resume path
• RunAsync

If useful, I can also share the exact dumped second-request payload, including the _attribution metadata showing the injected message as:

• sourceType: AIContextProvider
• sourceId: Microsoft.Agents.AI.TodoProvider

Current project configuration reference:

- `RunAsync`
- `ToolApprovalAgent` approval/resume path
- `DisableTodoProvider = false`
- `ChatHistoryProvider = new FileChatHistoryProvider(...)`
- no `MaxContextWindowTokens`
- no `MaxOutputTokens`
- no custom compaction strategy

[soul-soft]

I see two serious issues here. First, the Message provided by AiContextProvider should not be persisted to ChatHistoryProvider. Second, the Message provided by AiContextProvider should not be appended to messages that contain tool approval responses.

[moonbox3]

westey (@westey-m) note: per the triage bot's finding, this may be fixed.

[westey-m]

1448376744 (@soul-soft), thanks for logging the issue. Injecting synthetic user messages is actually a well supported scenario, and the provider is injecting the messages at the right location. The problem is lower down in the stack where approvals are handled and the function results for each approval is appended after the synthetic user message.

I've logged an issue and created a PR for fixing this here: dotnet/extensions#7616

Until the bug is fixed and shipped, one workaround is to use the responses service instead of chat completion. Chat Completion requires strict ordering, while responses does not. Responses also supports chat history storage outside of the service, similar to Chat Completion if that is a requirement. See this blog post for how to configure responses with the different storage modes.

Closing this issue, since it will be tracked further in the linked issue.