Fix broken multi-turn tool recursion and Anthropic tool result grouping

[Copilot]

handleCopilotMessage had a hand-rolled agent loop that only handled one round of tool calls. After executing a tool and re-calling streamChat, it processed content chunks but silently dropped any subsequent toolCall chunks — breaking multi-step workflows (e.g., search → download → add to timeline). A proper runAgentLoop with depth-limited recursion already existed but was never wired in.

WebSocket handler (handler.ts)

• Replaced broken inline agent loop with existing runAgentLoop which:
  • Collects all tool calls per turn before executing (parallel tool support)
  • Uses structured toolCalls/toolResults on Message instead of flat strings
  • Recurses up to 10 turns deep

REST API (routes/copilot.ts)

• Grouped tool results into a single user message (required by Anthropic for parallel tool use):

// Before: each result pushed as separate message — breaks Anthropic
for (const call of toolCalls) {
  messages.push({ role: 'user', content: '...', toolResults: [result] });
}

// After: single grouped message
messages.push({ role: 'user', content: '', toolResults: allResults });

• Pass executeTool to all loop iterations (was undefined after first call)

Tests

• websocket-tool-recursion-test.ts — validates 3-turn tool recursion across 2 tool executions
• rest-tool-grouping-test.ts — validates parallel tool results land in a single message

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[Copilot]

Pull request overview

This PR fixes broken multi-turn tool recursion by wiring the WebSocket chat flow to the existing runAgentLoop, and updates the REST /chat loop to group tool results into a single user message (required by Anthropic) while ensuring the tool executor is passed on subsequent iterations.

Changes:

• WebSocket: replaced the inline one-turn tool handling with runAgentLoop to support multi-turn tool recursion and structured tool messaging.
• REST: groups parallel tool results into a single toolResults message and passes executeTool to all loop iterations.
• Added standalone backend test scripts covering WebSocket multi-turn recursion and REST tool-result grouping.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 5 comments.

File	Description
apps/backend/src/websocket/handler.ts	Swaps in runAgentLoop for WebSocket multi-turn tool recursion.
apps/backend/src/routes/copilot.ts	Groups tool results into a single message and preserves executeTool across iterations.
apps/backend/src/test/websocket-tool-recursion-test.ts	Adds a script test validating 3-turn recursion with 2 tool executions over WebSocket.
apps/backend/src/test/rest-tool-grouping-test.ts	Adds a script test validating tool results are grouped into a single message for REST chat.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Switching the WebSocket path to runAgentLoop changes tool-result history from a textual user message to a structured toolResults message with content: ''. That breaks multi-turn tool flows for providers that ignore Message.toolResults (notably OpenAIProvider/CustomProvider, which only forward m.content to the API), because the model never sees tool outputs on the next turn and may loop/repeat tool calls. Consider either (a) adding an OpenAI message formatter that maps toolResults to the appropriate OpenAI tool/role messages, or (b) including a textual fallback summary of tool results in content when the active provider doesn't support structured toolResults.

[Copilot]

This tool-results message is now pushed with content: '' and only structured toolResults. That’s required for Anthropic, but it will break providers that don't serialize toolResults into their API payloads (e.g. OpenAIProvider currently only sends Message.content). To avoid losing tool outputs (and getting stuck in repeated tool calls / hitting MAX_ITERATIONS), either add provider-specific formatting for toolResults (OpenAI tool messages) or include a text fallback summary in content alongside the structured toolResults.

Suggested change

	// Add all tool results as a single user message (content is empty
	// because providers use the structured toolResults, not the text field)
	messages.push({
	role: 'user',
	content: '',
	// Add all tool results as a single user message.
	// Keep structured toolResults for providers that support them, and
	// also include a text fallback in `content` for providers that only
	// use the content field (e.g. some OpenAI-based providers).
	messages.push({
	role: 'user',
	content: toolResults
	.map(tr => {
	const resultText =
	typeof tr.result === 'string'
	? tr.result
	: JSON.stringify(tr.result);
	return `Tool "${tr.toolName}" (callId: ${tr.toolCallId}) returned${tr.isError ? ' error' : ''}: ${resultText}`;
	})
	.join('\n'),

[Copilot]

Unused imports LLMProviderOptions, MCPTool, ToolExecutor.

Suggested change

	import { LLMProviderInterface, MCPTool, StreamChunk, ToolCall, ToolExecutor, LLMProviderOptions } from '../llm/types.js';
	import { LLMProviderInterface, StreamChunk, ToolCall } from '../llm/types.js';

[Copilot]

Unused imports LLMProviderOptions, MCPTool, ToolExecutor.

Suggested change

	import { LLMProviderInterface, MCPTool, StreamChunk, ToolCall, ToolExecutor, LLMProviderOptions } from '../llm/types.js';
	import { LLMProviderInterface, StreamChunk, ToolCall } from '../llm/types.js';

[Copilot]

Unused variable wsHandler.

Suggested change

	const wsHandler = new WebSocketHandler(wss, projectManager, orchestrator);
	new WebSocketHandler(wss, projectManager, orchestrator);