Pipeline mode seems broken

[acoliver]

What happened?

/settings - set pipeline mode. None of the tool responses get added to the context. (see with /dumpcontext on). I ran with local models like Qwen 3 Next 80 b

What did you expect to happen?

the resposnes to get written.

Client information

v0.8.0-nightly.260102.9e1b7f4f6

Login information

No response

Anything else we need to know?

No response

[acoliver]

@CodeRabbit look into this

[coderabbitai]

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

@acoliver I'll investigate the pipeline mode issue where tool responses aren't being added to context.

---

🏁 Script executed:

#!/bin/bash
# Search for pipeline mode implementation
echo "=== Searching for 'pipeline' references ==="
rg -n -i "pipeline" --type=py -C 3

echo -e "\n=== Searching for 'dumpcontext' command ==="
rg -n -i "dumpcontext" --type=py -C 3

echo -e "\n=== Finding settings-related files ==="
fd -e py settings

echo -e "\n=== Searching for tool response handling ==="
rg -n "tool.*response" --type=py -C 3

Length of output: 174

---

🏁 Script executed:

#!/bin/bash
# Check repository structure
echo "=== Repository structure ==="
ls -la

echo -e "\n=== File types in the repository ==="
fd -e ts -e js -e py -e go -e rs | head -20

echo -e "\n=== Search for 'pipeline' in all text files ==="
rg -n -i "pipeline" -t ts -t js -t go -C 2 | head -50

echo -e "\n=== Search for 'dumpcontext' in all text files ==="
rg -n -i "dumpcontext" -t ts -t js -t go -C 2

echo -e "\n=== Search for 'settings' command ==="
rg -n "settings" -t ts -t js -t go -C 2 | head -50

Length of output: 44395

---

🏁 Script executed:

#!/bin/bash
# Find ToolCallPipeline implementation
echo "=== Finding ToolCallPipeline files ==="
fd -e ts -e js "ToolCallPipeline"

echo -e "\n=== Looking at ToolCallPipeline implementation ==="
cat packages/core/src/providers/openai/ToolCallPipeline.ts | head -200

echo -e "\n=== Finding setCommand ==="
fd -e ts -e js "setCommand"

echo -e "\n=== Searching for toolCallProcessingMode usage ==="
rg -n "toolCallProcessingMode" -t ts -C 5

Length of output: 24060

---

🏁 Script executed:

#!/bin/bash
# Look at setCommand implementation
echo "=== setCommand implementation ==="
cat packages/cli/src/ui/commands/setCommand.ts | head -150

echo -e "\n=== Searching for where tool responses are added to context ==="
rg -n "tool.*response" -t ts -C 3 --type-not=test | head -100

echo -e "\n=== Look at generateLegacyChatCompletionImpl and generatePipelineChatCompletionImpl ==="
rg -n "generateLegacyChatCompletionImpl|generatePipelineChatCompletionImpl" -t ts -C 2

echo -e "\n=== Find where tool execution results are handled ==="
rg -n "toolResult|tool_result" -t ts -C 3 | head -80

Length of output: 12656

---

🏁 Script executed:

#!/bin/bash
# Look at the pipeline implementation more carefully
echo "=== generatePipelineChatCompletionImpl implementation ==="
rg -n -A 100 "private async \*generatePipelineChatCompletionImpl" packages/core/src/providers/openai/OpenAIProvider.ts | head -150

echo -e "\n=== Check how tool_use content is yielded ==="
rg -n "tool_use|toolUse" packages/core/src/providers/openai/OpenAIProvider.ts -C 5 | head -100

echo -e "\n=== Look for where tool responses should be added to messages ==="
rg -n "addToolResponse|tool.*message" packages/core/src/providers/openai/OpenAIProvider.ts -C 3 | head -50

Length of output: 6386

---

🏁 Script executed:

#!/bin/bash
# Continue looking at the pipeline implementation
echo "=== Continue reading pipeline implementation ==="
rg -n -A 200 "private async \*generatePipelineChatCompletionImpl" packages/core/src/providers/openai/OpenAIProvider.ts | head -400

echo -e "\n=== Look at legacy implementation to compare ==="
rg -n -A 80 "private async \*generateLegacyChatCompletionImpl" packages/core/src/providers/openai/OpenAIProvider.ts | head -150

echo -e "\n=== Search for where tool call content is yielded in both modes ==="
rg -n "yield.*tool.*call|ContentType.TOOL_CALL" packages/core/src/providers/openai/OpenAIProvider.ts -C 3

Length of output: 11989

---

🏁 Script executed:

#!/bin/bash
# Look for where the pipeline yields tool call content
echo "=== Search for yield statements in pipeline implementation ==="
sed -n '3081,3500p' packages/core/src/providers/openai/OpenAIProvider.ts | grep -n "yield" -A 3 -B 3

echo -e "\n=== Look at the entire pipeline streaming section ==="
sed -n '3280,3500p' packages/core/src/providers/openai/OpenAIProvider.ts

echo -e "\n=== Check ContentType enum ==="
rg -n "ContentType\.(TOOL_CALL|TOOL_RESULT)" packages/core/src -t ts | head -20

Length of output: 8346

---

🏁 Script executed:

#!/bin/bash
# Look at the rest of the pipeline implementation - where responses are processed
echo "=== Look at pipeline streaming response processing ==="
sed -n '3500,3800p' packages/core/src/providers/openai/OpenAIProvider.ts

echo -e "\n=== Look at where normalized tool calls are used ==="
rg -n "normalized.*tool|pipelineResult" packages/core/src/providers/openai/OpenAIProvider.ts -C 5 | head -100

echo -e "\n=== Compare with legacy mode - search for tool content yielding ==="
sed -n '1532,2000p' packages/core/src/providers/openai/OpenAIProvider.ts | grep -n "type.*tool\|ContentType\|yield" -i | head -50

Length of output: 13511

---

🏁 Script executed:

#!/bin/bash
# Look for where the pipeline result is processed and yielded
echo "=== Find where pipeline results are yielded ==="
sed -n '3800,4200p' packages/core/src/providers/openai/OpenAIProvider.ts | head -200

echo -e "\n=== Search for where tool calls are yielded in legacy mode ==="
sed -n '1800,2200p' packages/core/src/providers/openai/OpenAIProvider.ts | grep -n "yield\|type.*tool_call" -A 5 -B 2 | head -80

Length of output: 8810

---

🏁 Script executed:

#!/bin/bash
# Find where pipeline process() is called and results are yielded
echo "=== Find where pipeline.process() is called ==="
rg -n "toolCallPipeline\.process|cachedPipelineResult" packages/core/src/providers/openai/OpenAIProvider.ts -C 10 | head -150

echo -e "\n=== Look at the specific section where results are yielded after streaming ==="
sed -n '4200,4500p' packages/core/src/providers/openai/OpenAIProvider.ts

Length of output: 16523

---

🏁 Script executed:

#!/bin/bash
# Look at how tool execution and results are handled in the core/CLI layer
echo "=== Search for tool execution handling ==="
rg -n "executeTool|handleToolCall|tool.*execution" packages/cli/src -t ts -C 3 | head -80

echo -e "\n=== Look for ConversationManager or context handling ==="
fd -e ts "Conversation|Context" packages/cli/src | head -20

echo -e "\n=== Search for where IContent is consumed and added to history ==="
rg -n "speaker.*ai.*blocks.*tool_call|addToHistory|updateContext" packages/cli/src -t ts -C 3 | head -50

Length of output: 7433

---

🏁 Script executed:

#!/bin/bash
# Look at ConversationContext to understand how messages are stored
echo "=== ConversationContext implementation ==="
cat packages/cli/src/utils/ConversationContext.ts | head -200

echo -e "\n=== Search for where tool results/responses are added to conversation ==="
rg -n "tool_result|toolResult|ToolResult" packages/cli/src -t ts -C 3 | head -100

echo -e "\n=== Look for the tool scheduler that handles tool execution ==="
cat packages/cli/src/ui/hooks/useToolScheduler.ts | head -150

Length of output: 9711

---

🏁 Script executed:

#!/bin/bash
# Find the tool scheduler
echo "=== Find tool scheduler files ==="
fd "ToolScheduler|toolScheduler" packages/cli/src

echo -e "\n=== Search for where IContent with tool_call blocks is processed ==="
rg -n "type.*tool_call|ToolCallBlock" packages/cli/src -t ts -C 3 | head -80

echo -e "\n=== Look for where tool execution results get added to context ==="
rg -n "addMessage|appendContent|pushContent" packages/cli/src -t ts -C 3 | head -60

Length of output: 11237

---

🏁 Script executed:

#!/bin/bash
# Look at the React tool scheduler
echo "=== Look at useReactToolScheduler ==="
cat packages/cli/src/ui/hooks/useReactToolScheduler.ts | head -300

echo -e "\n=== Search for where tool results are converted to IContent ==="
rg -n "functionResponse|tool_result|FunctionResponsePart" packages/core/src -t ts -C 3 | head -100

Length of output: 16477

---

🏁 Script executed:

#!/bin/bash
# Look at how tool completion is handled and responses added to history
echo "=== Look at more of useReactToolScheduler - onComplete handling ==="
cat packages/cli/src/ui/hooks/useReactToolScheduler.ts | tail -100

echo -e "\n=== Search for convertToFunctionResponse or where tool results become Parts ==="
rg -n "convertToFunctionResponse|toFunctionResponsePart" packages/core/src -t ts -C 5 | head -100

echo -e "\n=== Look for where completed tools are added to conversation ==="
rg -n "onAllToolCallsComplete|CompletedToolCall" packages/cli/src/ui -t ts -C 3 | head -80

Length of output: 17411

---

🏁 Script executed:

#!/bin/bash
# Look at how recordCompletedToolCalls works
echo "=== Search for recordCompletedToolCalls implementation ==="
rg -n "recordCompletedToolCalls" packages/core/src -t ts -A 20 | head -100

echo -e "\n=== Look at GeminiChat to see how tool responses are added to context ==="
fd "GeminiChat" packages/core/src | head -5

echo -e "\n=== Check if there's a difference in context handling between pipeline and legacy ==="
rg -n "legacy.*tool|pipeline.*tool" packages/core/src/providers/openai/OpenAIProvider.ts -C 5 | head -80

Length of output: 5578

---

@acoliver I've found the issue! The problem is not with the pipeline mode yielding tool calls, but with how tool responses are added back to the conversation context.

---

🏁 Script executed:

#!/bin/bash
# Verify where tool responses should be added to context
echo "=== Look at where tool responses are converted to Content ==="
rg -n "responseParts|toolResponse|tool.*response.*context" packages/core/src -t ts -C 5 | head -100

echo -e "\n=== Check how messages/history is built in both modes ==="
rg -n "buildMessages|convertToOpenAI|history.*tool" packages/core/src/providers/openai/OpenAIProvider.ts -C 3 | head -80

echo -e "\n=== Look at CompletedToolCall structure ==="
rg -n "interface CompletedToolCall|type CompletedToolCall" packages/core/src -t ts -C 10 | head -50

Length of output: 15846

---

🏁 Script executed:

#!/bin/bash
# Look for CompletedToolCall definition and responseParts
echo "=== CompletedToolCall definition ==="
rg -n "status.*success.*CompletedToolCall|CompletedToolCall.*=" packages/core/src/core -t ts -A 5 | head -60

echo -e "\n=== Search for how responseParts gets converted to IContent ==="
rg -n "responseParts.*IContent|response\.responseParts|tool_response.*block" packages/cli/src packages/core/src -t ts -C 5 | head -100

echo -e "\n=== Look for where tool responses are added after tool execution completes ==="
rg -n "speaker.*tool|blocks.*tool_response" packages/cli/src/ui/hooks -t ts -C 5 | head -80

Length of output: 14541

---

I've found the root cause! The issue is that tool responses are not being added back to the conversation context in pipeline mode. Let me create a comprehensive analysis:

---

🏁 Script executed:

#!/bin/bash
# Verify how tool responses should be added to history
echo "=== Look for how tool responses are converted from CompletedToolCall to IContent ==="
rg -n "responseParts.*speaker.*tool|convertToolResponse|toolResponseToContent" packages/cli/src packages/core/src -t ts -C 5 | head -80

echo -e "\n=== Check how Gemini handles tool response history ==="
rg -n "addHistory.*tool|recordHistory.*tool" packages/core/src/core/geminiChat.ts -C 5 | head -60

echo -e "\n=== Look at where OpenAI provider should add tool responses but doesn't ==="
rg -n "OpenAI.*tool.*response|openai.*history.*tool" packages/core/src/providers/openai -t ts -C 3 | head -60

Length of output: 2796

---

@acoliver I've completed my investigation of issue #981. I found the root cause of the pipeline mode issue where tool responses aren't being added to context.

Problem Summary

The issue affects the OpenAI provider when using pipeline mode (toolCallProcessingMode: 'pipeline'). Here's what's happening:

1. ✅ Tool calls ARE correctly yielded - The pipeline properly processes and yields tool call IContent blocks
2. ✅ Tools ARE executed - The CoreToolScheduler successfully executes tools
3. ❌ Tool responses are NOT added to context - The responses from completed tools aren't being added back to the conversation history for subsequent LLM turns

Root Cause

The tool responses live in CompletedToolCall.response.responseParts (as Gemini Part[] format with functionResponse parts). These need to be:

1. Converted from Part[] to IContent format with speaker: 'tool' and tool_response blocks
2. Added to the conversation history
3. Passed to the next provider call in the contents array

The bug: This conversion and history management happens correctly for Gemini (see useGeminiStream.ts lines 1300-1352), but is missing for OpenAI and other providers when using pipeline mode.

Key Files Involved

• packages/core/src/providers/openai/OpenAIProvider.ts - Pipeline implementation (yields tool calls correctly)
• packages/core/src/providers/openai/ToolCallPipeline.ts - Tool call collection/normalization
• packages/cli/src/ui/hooks/useGeminiStream.ts - Handles tool responses for Gemini only
• packages/core/src/core/coreToolScheduler.ts - Produces CompletedToolCall with responseParts

Additional Finding

The toolCallProcessingMode setting defaults to 'legacy' (line 192 in OpenAIProvider.ts, line 333 in settingsSchema.ts), so users need to explicitly set it to 'pipeline' in their settings.json - it's not available via the /set command as it's a persistent (not ephemeral) setting.

Recommended Fix

The fix needs to be implemented in the CLI layer where tool completion is handled. Specifically, when onComplete is called with CompletedToolCall[], the code needs to:

1. Extract response.responseParts from each completed tool call
2. Convert these Parts to IContent with appropriate tool_response blocks
3. Add them to the conversation history service
4. Ensure they're included in the next provider invocation

Would you like me to investigate the specific code locations where this fix should be implemented, or would you prefer to assign this to a developer with that guidance?

[acoliver]

@CodeRabbit but it was working in the past... was this changed when we fixed some of the scheduler issues?

[coderabbitai]

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Search for recent scheduler-related changes
echo "=== Recent commits mentioning 'scheduler' ==="
git log --all --oneline --grep="scheduler" -20

echo -e "\n=== Recent commits mentioning 'tool response' or 'tool result' ==="
git log --all --oneline --grep="tool response\|tool result" -20

echo -e "\n=== Git history of useReactToolScheduler.ts ==="
git log --oneline packages/cli/src/ui/hooks/useReactToolScheduler.ts -15

echo -e "\n=== Git history of useGeminiStream.ts (has working tool response handling) ==="
git log --oneline packages/cli/src/ui/hooks/useGeminiStream.ts -15

echo -e "\n=== Recent commits to OpenAIProvider.ts ==="
git log --oneline packages/core/src/providers/openai/OpenAIProvider.ts -15

Length of output: 3497

---

🏁 Script executed:

#!/bin/bash
# Check for PRs related to pipeline mode and tool responses
echo "=== Search for 'pipeline' in recent commit messages ==="
git log --all --oneline --grep="pipeline" -20

echo -e "\n=== Search for 'context' related to tools ==="
git log --all --oneline --grep="context.*tool\|tool.*context" -15

echo -e "\n=== Look at recent changes to tool response handling ==="
git log --all --oneline --since="2024-11-01" -- "**/useReactToolScheduler.ts" "**/useGeminiStream.ts" "**/OpenAIProvider.ts" | head -30

echo -e "\n=== Check for commits that mention fixing scheduler issues ==="
git log --all --oneline --grep="fix.*scheduler\|scheduler.*fix\|scheduler.*issue" -20

Length of output: 5182

---

🏁 Script executed:

#!/bin/bash
# Look at specific commit diffs for scheduler fixes
echo "=== Find commits with 'scheduler' in message from last 3 months ==="
git log --all --oneline --since="2024-10-01" --grep="scheduler" | head -20

echo -e "\n=== Show recent commits that modified tool response handling ==="
git log --all --oneline --since="2024-11-01" -S "responseParts" --source --all | head -20

echo -e "\n=== Check for changes to how tool responses are added to context ==="
git log --all --oneline --since="2024-11-01" -S "speaker.*tool\|tool.*context" -- "packages/cli/src/ui/hooks/*.ts" | head -20

Unrecoverable error: Request timed out after 300000ms (requestId=c893d3b9-68dd-48a8-84ab-54890c01f3a7)

---

🏁 Script executed:

#!/bin/bash
# Look for when tool response context handling might have been removed
echo "=== Search git history for removal of tool response context code ==="
git log --all --oneline -S "speaker: 'tool'" --source --all | head -30

echo -e "\n=== Check recent refactoring commits ==="
git log --all --oneline --since="2024-11-01" --grep="refactor" | head -30

echo -e "\n=== Look at commits that changed useOpenAI or OpenAI hooks ==="
git log --all --oneline --since="2024-11-01" -- "packages/cli/src/ui/hooks/useOpenAI*.ts" | head -20

Unrecoverable error: Request timed out after 300000ms (requestId=a3850766-2548-43e8-952c-defd85a01f58)

---

🏁 Script executed:

#!/bin/bash
# Look at the tool-call history fix commit
echo "=== Show commit 2f3b902e (Fix tool-call history for provider switching) ==="
git show 2f3b902e --stat

echo -e "\n=== Show the actual diff for that commit ==="
git show 2f3b902e --no-patch --format=fuller

echo -e "\n=== Check what files were changed in that commit ==="
git diff-tree --no-commit-id --name-only -r 2f3b902e

Length of output: 2410

---

🏁 Script executed:

#!/bin/bash
# Look at the scheduler unification commit
echo "=== Show commit c7e0c003 (unify non-interactive tool execution with scheduler) ==="
git show c7e0c003 --stat

echo -e "\n=== Get details of that commit ==="
git show c7e0c003 --no-patch --format=fuller

echo -e "\n=== Files changed in scheduler unification ==="
git diff-tree --no-commit-id --name-only -r c7e0c003

Length of output: 1870

---

🏁 Script executed:

#!/bin/bash
# Check the enforce tool output ephemerals commit
echo "=== Show commit 0b898a3b (enforce tool output ephemerals) ==="
git show 0b898a3b --stat

echo -e "\n=== Files changed ==="
git diff-tree --no-commit-id --name-only -r 0b898a3b

Length of output: 3331

---

🏁 Script executed:

#!/bin/bash
# Look at specific changes to how tool responses are handled
echo "=== Check diff of useReactToolScheduler in recent commits ==="
git log --oneline -10 -- packages/cli/src/ui/hooks/useReactToolScheduler.ts

echo -e "\n=== Check specific changes to tool response handling in OpenAI hooks ==="
git log --oneline -10 -- "packages/cli/src/ui/hooks/useOpenAI*.ts"

Length of output: 1321

---

🏁 Script executed:

#!/bin/bash
# Compare current useReactToolScheduler with a few commits back
echo "=== Show recent changes to useReactToolScheduler.ts ==="
git log -p -3 -- packages/cli/src/ui/hooks/useReactToolScheduler.ts | head -400

Length of output: 55

---

🏁 Script executed:

#!/bin/bash
# Look at the tool-call history fix to see what was changed
echo "=== Show the diff for HistoryService.ts in commit 2f3b902e ==="
git show 2f3b902e -- packages/core/src/services/history/HistoryService.ts | head -200

echo -e "\n=== Show changes to useGeminiStream.ts in that commit ==="
git show 2f3b902e -- packages/cli/src/ui/hooks/useGeminiStream.ts | head -150

Length of output: 9608

---

🏁 Script executed:

#!/bin/bash
# Check if there's a corresponding OpenAI stream hook
echo "=== Find OpenAI stream-related hooks ==="
fd -e ts -e tsx "useOpenAI" packages/cli/src/ui/hooks

echo -e "\n=== Check what hooks exist for OpenAI ==="
ls -la packages/cli/src/ui/hooks/ | grep -i openai

echo -e "\n=== Search for where OpenAI provider is used in hooks ==="
rg -n "OpenAIProvider" packages/cli/src/ui/hooks -t ts -C 2 | head -50

Length of output: 2516

---

🏁 Script executed:

#!/bin/bash
# Look at what the plan for issue 864 said
echo "=== Read the plan for issue 864 (tool-call history fix) ==="
cat project-plans/20251218issue864/plan.md

Length of output: 7375

---

🏁 Script executed:

#!/bin/bash
# Check if pipeline mode uses a different code path
echo "=== Search for how OpenAI with pipeline mode yields results ==="
rg -n "generatePipelineChatCompletionImpl|pipeline.*mode" packages/cli/src -t ts -C 3 | head -80

echo -e "\n=== Check if there's a hook that handles OpenAI streaming ==="
cat packages/cli/src/ui/hooks/useProvider.ts | head -100

Length of output: 199

---

🏁 Script executed:

#!/bin/bash
# Look for where tool responses should be added for OpenAI
echo "=== Search for tool response handling in CLI hooks ==="
rg -n "CompletedToolCall|onComplete.*tool" packages/cli/src/ui/hooks -t ts -C 5 | head -150

Length of output: 12252

---

🏁 Script executed:

#!/bin/bash
# Look at what the "textual tool replay" removal changed
echo "=== Show the OpenAI textual tool replay removal in commit 0b898a3b ==="
git show 0b898a3b -- packages/core/src/providers/openai/OpenAIProvider.ts | grep -A 30 -B 5 "textual\|replay\|tool.*response.*history" | head -100

Length of output: 4545

---

🏁 Script executed:

#!/bin/bash
# Check if there was code that added tool responses to history in OpenAI
echo "=== Search for removed code that added tool responses ==="
git show 0b898a3b -- packages/core/src/providers/openai/OpenAIProvider.ts | grep -A 10 -B 10 "addHistory\|recordHistory\|tool.*response.*context" | head -150

Length of output: 57

---

🏁 Script executed:

#!/bin/bash
# Look at the full diff of OpenAIProvider.ts in the ephemeral enforcement commit
echo "=== Show statistics of what was removed from OpenAIProvider ==="
git diff 0b898a3b^..0b898a3b --stat packages/core/src/providers/openai/OpenAIProvider.ts

echo -e "\n=== Show the actual removal of textual replay code ==="
git diff 0b898a3b^..0b898a3b packages/core/src/providers/openai/OpenAIProvider.ts | grep -A 20 "^-.*textual\|^-.*replay" | head -100

Length of output: 4423

---

🏁 Script executed:

#!/bin/bash
# Check what OpenAIProvider looked like before the removal
echo "=== Show OpenAIProvider at commit before textual replay removal ==="
git show 0b898a3b^:packages/core/src/providers/openai/OpenAIProvider.ts | grep -n "textual\|replay" -A 5 -B 5 | head -80

Length of output: 3159

---

@acoliver Yes, you're absolutely right! I found the regression. This was broken by the Dec 18 commit that "fixed" tool output ephemerals.

Timeline of the Regression

December 18, 2025 - Commit 0b898a3b

• Removed "legacy OpenAI textual tool replay pathway"
• Deleted 209 lines from OpenAIProvider.ts, including the buildMessagesWithToolReplay() method
• Replaced it with buildMessagesWithReasoning()

December 19, 2025 - Commit 2f3b902e

• Fixed tool-call history for Gemini only by adding explicit tool response recording in useGeminiStream.ts:

  // Lines 1300-1352: Split responseParts into functionCalls and functionResponses
  // and add them to geminiClient.addHistory() with proper roles

• OpenAI never got the equivalent fix

The Problem

OpenAI providers use a stateless API where each call starts off with no prior context, requiring manual conversation history management. The llxprt-code codebase handles this through HistoryService, but when tool execution completes, something needs to explicitly convert the CompletedToolCall.response.responseParts into IContent and add it to history.

Here's what happened:

1. Gemini got the fix (Dec 19) - useGeminiStream.ts now explicitly splits responseParts into separate history entries with correct roles:

   • functionCall parts → role:'model' (assistant)
   • functionResponse parts → role:'user' (tool results)

2. OpenAI never got the equivalent - There's no useOpenAIStream.ts hook to handle this conversion. Tool responses from the scheduler just... disappear into the void.

The Fix Needed

OpenAI needs a mechanism (either a dedicated hook like useOpenAIStream.ts or within the shared scheduler completion handler) that:

1. Takes CompletedToolCall[] from onComplete callback
2. Extracts response.responseParts (Gemini Part[] format)
3. Converts them to IContent with speaker:'tool' and tool_response blocks
4. Adds them to HistoryService
5. Ensures they're passed in the next provider call

Would you like me to investigate where this conversion should happen - in a new OpenAI-specific hook, or in a shared provider-agnostic layer?

---

🧠 Learnings used

Learnt from: e2720pjk
Repo: vybestack/llxprt-code PR: 583
File: packages/core/src/providers/openai/OpenAIProvider.ts:935-959
Timestamp: 2025-11-16T22:51:26.374Z
Learning: In the llxprt-code codebase (packages/core/src/providers/openai/OpenAIProvider.ts), tools like `run_shell_command` use internal streaming only for real-time UI updates during execution, but each tool execution produces exactly ONE final `ToolResponseBlock` containing the full result. The streaming chunks are never sent to the LLM and are not converted into multiple tool messages. The OpenAI Chat Completions API requires that each tool call (tool_call_id) corresponds to exactly one message with role 'tool', so duplicate tool response detection that removes subsequent tool messages with the same tool_call_id is correct and necessary for API compliance.

---

Learnt from: acoliver
Repo: vybestack/llxprt-code PR: 0
File: :0-0
Timestamp: 2025-12-18T14:06:22.557Z
Learning: OpenAIResponsesProvider (packages/core/src/providers/openai-responses/OpenAIResponsesProvider.ts) currently bypasses the ephemeral truncation system by using direct `JSON.stringify(toolResponseBlock.result)` and needs to be updated to support ephemeral settings like the other providers.

[acoliver]

@CodeRabbit but the problem is in pipeline mode... you're making is sound general to OpenAIProvider -- it is fine in legacy mode ?

[coderabbitai]

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

@acoliver You're absolutely right to question that - let me investigate the specific difference between legacy and pipeline mode for tool response handling.

---

🏁 Script executed:

#!/bin/bash
# Check how buildMessagesWithReasoning handles tool responses
echo "=== Look at buildMessagesWithReasoning implementation ==="
rg -n "buildMessagesWithReasoning" packages/core/src/providers/openai/OpenAIProvider.ts -A 50 | head -100

echo -e "\n=== Check if legacy mode has different tool response handling ==="
rg -n "generateLegacyChatCompletionImpl" packages/core/src/providers/openai/OpenAIProvider.ts -A 100 | grep -i "tool.*response\|buildMessages" | head -30

echo -e "\n=== Compare how messages are built in both modes ==="
rg -n "this\.buildMessages" packages/core/src/providers/openai/OpenAIProvider.ts -C 3 | head -80

Length of output: 5468

---

🏁 Script executed:

#!/bin/bash
# Check if there's a difference in how tool results flow back to context
echo "=== Search for where tool responses are added in legacy vs pipeline ==="
rg -n "toolResult|tool_result|ToolResponseBlock" packages/core/src/providers/openai/OpenAIProvider.ts -C 3 | head -100

echo -e "\n=== Look for any conditional logic based on toolCallProcessingMode ==="
rg -n "toolCallProcessingMode.*legacy|toolCallProcessingMode.*pipeline" packages/core/src/providers/openai/OpenAIProvider.ts -C 5

echo -e "\n=== Check how messages array is used in both modes ==="
rg -n "messages.*tool|convertToOpenAI.*tool" packages/core/src/providers/openai/OpenAIProvider.ts -C 3 | head -80

Length of output: 3488

---

🏁 Script executed:

#!/bin/bash
# Check what the removed buildMessagesWithToolReplay did
echo "=== Show what buildMessagesWithToolReplay looked like before removal ==="
git show 0b898a3b^:packages/core/src/providers/openai/OpenAIProvider.ts | grep -n "buildMessagesWithToolReplay" -A 80 | head -150

Length of output: 72

---

🏁 Script executed:

#!/bin/bash
# Check if legacy mode automatically includes tool responses from history
echo "=== Look at how HistoryService is used in OpenAIProvider ==="
rg -n "this\.historyService|historyService\.get" packages/core/src/providers/openai/OpenAIProvider.ts -C 3 | head -80

echo -e "\n=== Check if tool responses are in history automatically ==="
rg -n "speaker.*tool|role.*tool" packages/core/src/services/history/HistoryService.ts -C 3 | head -50

Length of output: 2019

---

🏁 Script executed:

#!/bin/bash
# Check if legacy mode yields tool responses differently
echo "=== Look at how legacy mode yields tool results ==="
sed -n '1532,2500p' packages/core/src/providers/openai/OpenAIProvider.ts | grep -n "yield\|tool_result\|ToolResponseBlock\|speaker.*tool" -A 3 -B 3 | head -150

Length of output: 1873

---

🏁 Script executed:

#!/bin/bash
# Check if there's a difference in how useReactToolScheduler handles completions for different modes
echo "=== Look at useReactToolScheduler onComplete callback ==="
cat packages/cli/src/ui/hooks/useReactToolScheduler.ts | grep -n "onComplete\|recordCompletedToolCalls" -A 10 -B 3 | head -80

echo -e "\n=== Check if recordCompletedToolCalls is provider-specific ==="
rg -n "recordCompletedToolCalls" packages/core/src -t ts -A 10 | head -100

Length of output: 3198

---

🏁 Script executed:

#!/bin/bash
# Check if legacy mode somehow adds tool responses automatically through IContent
echo "=== Search for how tool responses are created as IContent ==="
rg -n "speaker:.*'tool'|speaker: 'tool'" packages/cli/src packages/core/src -t ts -C 3 | head -100

Length of output: 7759

---

🏁 Script executed:

#!/bin/bash
# Check what happens after tools complete in the CLI layer
echo "=== Look at how the provider stream is consumed ==="
rg -n "for await.*provider|processContent|handleContent" packages/cli/src/ui/hooks -t ts -C 5 | head -100

Length of output: 2552

---

🏁 Script executed:

#!/bin/bash
# Check if there's a difference in how contents flow in legacy vs pipeline
echo "=== Look for any pipeline-specific content handling ==="
rg -n "pipeline.*content|legacy.*content" packages/cli/src packages/core/src -t ts -C 3 | head -60

Length of output: 2127

---

🏁 Script executed:

#!/bin/bash
# Look at how tool execution results flow back in legacy mode
echo "=== Check if legacy mode waits for tool execution before continuing ==="
sed -n '1532,3000p' packages/core/src/providers/openai/OpenAIProvider.ts | grep -n "tool.*execution\|await.*tool\|scheduleToolCalls" -A 5 -B 5 | head -100

Length of output: 71

---

🏁 Script executed:

#!/bin/bash
# Check what useProviderStream does - the common OpenAI/Anthropic handler
echo "=== Look for useProviderStream or similar OpenAI stream consumer ==="
fd -e ts -e tsx "useProvider" packages/cli/src/ui/hooks

echo -e "\n=== Check if there's a generic provider stream handler ==="
cat packages/cli/src/ui/hooks/useProviderStream.ts 2>/dev/null | head -200 || echo "File not found"

Length of output: 227

---

🏁 Script executed:

#!/bin/bash
# Check how the CLI consumes OpenAI provider streams
echo "=== Look for where OpenAI provider stream is consumed in UI ==="
rg -n "OpenAIProvider.*generate|provider.*generate.*OpenAI" packages/cli/src/ui -t ts -C 5 | head -80

Length of output: 63

---

🏁 Script executed:

#!/bin/bash
# Find where tool responses are supposed to be added to history/context
echo "=== Look for where historyService.add is called with tool speaker ==="
rg -n "historyService\.add.*tool|add.*speaker.*tool" packages/cli/src -t ts -C 5 | head -80

echo -e "\n=== Check ConversationContext addMessage ==="
cat packages/cli/src/utils/ConversationContext.ts | grep -n "addMessage\|add.*tool" -A 10 | head -80

Length of output: 115

---

🏁 Script executed:

#!/bin/bash
# The critical question: in legacy mode, does the provider ITSELF yield tool responses?
echo "=== Check if legacy mode yields tool_response blocks ==="
sed -n '1532,3000p' packages/core/src/providers/openai/OpenAIProvider.ts | grep -n "type.*tool_response\|speaker.*tool\|ToolResponseBlock" -A 3 -B 3 | head -80

Length of output: 56

---

🏁 Script executed:

#!/bin/bash
# Check what IContent gets yielded in both modes - look at the actual yield statements
echo "=== Legacy mode - all yield statements ==="
sed -n '1532,2800p' packages/core/src/providers/openai/OpenAIProvider.ts | grep -n "yield {" -A 10 | head -150

Length of output: 4494

---

🏁 Script executed:

#!/bin/bash
# Check what IContent gets yielded in pipeline mode - all yield statements
echo "=== Pipeline mode - all yield statements ==="
sed -n '3081,4500p' packages/core/src/providers/openai/OpenAIProvider.ts | grep -n "yield {" -A 10 | head -150

Length of output: 4572

---

🏁 Script executed:

#!/bin/bash
# Critical: Check if Gemini provider yields tool_response blocks
echo "=== Check if Gemini yields tool_response blocks ==="
rg -n "type:.*'tool_response'|type: 'tool_response'" packages/core/src/core/geminiChat.ts -C 5

Length of output: 1087

---

🏁 Script executed:

#!/bin/bash
# Check how useGeminiStream adds tool responses to history
echo "=== Look at useGeminiStream tool completion handler ==="
sed -n '1250,1400p' packages/cli/src/ui/hooks/useGeminiStream.ts

Length of output: 4723

---

🏁 Script executed:

#!/bin/bash
# Check how the main UI consumes provider streams - find the message loop
echo "=== Find where provider streams are consumed ==="
rg -n "for await.*content|await.*provider.*generate" packages/cli/src/App.tsx packages/cli/src/ui/App.tsx -C 10 | head -100

Length of output: 113

---

🏁 Script executed:

#!/bin/bash
# This is the KEY question - does legacy mode get tool responses from HistoryService automatically?
echo "=== Check what was in buildMessagesWithToolReplay that got removed ==="
git log --all --oneline -S "buildMessagesWithToolReplay" | head -10

echo -e "\n=== Show the actual removal of buildMessagesWithToolReplay ==="
git log -p --all -S "buildMessagesWithToolReplay" -- packages/core/src/providers/openai/OpenAIProvider.ts | head -300

Unrecoverable error: Request timed out after 300000ms (requestId=03d1a25e-5a30-4f43-a1cc-a5470425e2a2)

---

🏁 Script executed:

#!/bin/bash
# Check if the CLI layer adds tool responses to HistoryService after tools complete
echo "=== Search for where completed tools are added to history ==="
rg -n "completedToolCall|CompletedToolCall" packages/cli/src -t ts -C 5 | grep -i "history\|add\|context" | head -50

Length of output: 1082

---

🏁 Script executed:

#!/bin/bash
# Look at what App.tsx or main UI file does
echo "=== Find the main UI entry point ==="
fd "App" packages/cli/src --type f | head -10

echo -e "\n=== Look for the main conversation loop ==="
rg -n "for await|provider.*generate" packages/cli/src/ui/screens -t ts -C 5 | head -100

Length of output: 659

---

🏁 Script executed:

#!/bin/bash
# Critical: Check if buildMessagesWithReasoning reads tool responses from contents parameter
echo "=== Look at buildMessagesWithReasoning handling of tool messages ==="
sed -n '1209,1350p' packages/core/src/providers/openai/OpenAIProvider.ts

Length of output: 5654

---

@acoliver You're absolutely right to call that out! Let me clarify.

Looking at the code, I found that buildMessagesWithReasoning() DOES handle tool responses - it converts IContent with speaker: 'tool' into OpenAI tool messages (lines 1327-1344). So the mechanism to include tool responses in the API call exists.

The critical issue is: Where do these tool response IContent blocks come from?

I discovered that:

1. Neither legacy NOR pipeline mode yields tool_response blocks - both only yield tool_call blocks with speaker: 'ai'
2. Gemini DOES yield tool_response blocks (in geminiChat.ts lines 2452, 2488)
3. useGeminiStream explicitly adds completed tool responses to geminiClient.addHistory() after execution

So here's my hypothesis:

The removed buildMessagesWithToolReplay() method (209 lines deleted in commit 0b898a3) likely synthesized tool response IContent blocks and added them to the conversation context/history in legacy mode. When that was removed, legacy mode probably broke too.

Can you confirm whether legacy mode is actually working when you test with /settings and set toolCallProcessingMode to legacy? If legacy mode is also broken, then my original analysis stands - the regression affects OpenAI provider generally, not just pipeline mode.

If legacy mode IS working, then there must be another mechanism I haven't found that adds tool responses to history in legacy mode but not pipeline mode.

---

🧠 Learnings used

Learnt from: e2720pjk
Repo: vybestack/llxprt-code PR: 583
File: packages/core/src/providers/openai/OpenAIProvider.ts:935-959
Timestamp: 2025-11-16T22:51:26.374Z
Learning: In the llxprt-code codebase (packages/core/src/providers/openai/OpenAIProvider.ts), tools like `run_shell_command` use internal streaming only for real-time UI updates during execution, but each tool execution produces exactly ONE final `ToolResponseBlock` containing the full result. The streaming chunks are never sent to the LLM and are not converted into multiple tool messages. The OpenAI Chat Completions API requires that each tool call (tool_call_id) corresponds to exactly one message with role 'tool', so duplicate tool response detection that removes subsequent tool messages with the same tool_call_id is correct and necessary for API compliance.

---

Learnt from: acoliver
Repo: vybestack/llxprt-code PR: 0
File: :0-0
Timestamp: 2025-12-18T14:06:22.557Z
Learning: OpenAIResponsesProvider (packages/core/src/providers/openai-responses/OpenAIResponsesProvider.ts) currently bypasses the ephemeral truncation system by using direct `JSON.stringify(toolResponseBlock.result)` and needs to be updated to support ephemeral settings like the other providers.

---

Learnt from: acoliver
Repo: vybestack/llxprt-code PR: 0
File: :0-0
Timestamp: 2025-12-26T14:17:41.983Z
Learning: In packages/core/src/core/coreToolScheduler.ts, the `publishBufferedResults()` method (line 1355) is called concurrently by multiple tool completion handlers (line 1510 in each tool's `.then()` callback) when parallel tools finish simultaneously. This causes a race condition where `nextPublishIndex` can be corrupted and tools can hang in 'executing' state forever, blocking the scheduler and causing subsequent tool calls to queue indefinitely. The method must be made reentrant-safe using a mutex/lock pattern to serialize concurrent calls.