Compaction fails on Bedrock-backed providers: missing toolConfig

[sledigabel]

Description

When using an OpenAI-compatible provider backed by AWS Bedrock (via Portkey), compaction fails with:

bedrock error: The toolConfig field must be defined when using toolUse and toolResult content blocks.

During compaction, opencode sends conversation history containing toolUse/toolResult blocks with tools: {}. Bedrock requires a toolConfig whenever messages contain tool content blocks.

A _noop tool injection workaround existed but was removed in 7f7eb2e (#26819) when LiteLLM fixed the issue upstream. The underlying Bedrock API constraint still applies for non-LiteLLM proxies.

Plugins

N/A

OpenCode version

v1.2.23+ (regression introduced in v1.2.23, v1.2.22 unaffected)

Steps to reproduce

1. Configure an @ai-sdk/openai-compatible provider backed by Bedrock (e.g. Portkey with x-portkey-config routing to Bedrock)
2. Use a session using tools (or type something like "check git")
3. Trigger compaction (/compact)
4. Observe the Bedrock error

Screenshot and/or share link

Operating System

macOS 26.5

Terminal

Ghostty

Related issues

may relate to #29428

[github-actions]

This issue might be a duplicate of an existing (now closed) issue. Please check:

• Compaction fails with Bedrock: toolConfig not included when conversation has tool history #10259: Compaction fails with Bedrock: toolConfig not included when conversation has tool history — identical root cause (missing toolConfig during compaction when messages contain toolUse/toolResult blocks, same error message, same Portkey+Bedrock setup)

The referenced fix in #26819 (removal of the noop tool injection) may be the regression vector. It might be worth reopening or referencing #10259 to track the fix.

[Robin1987China]

Investigating this on the v2 branch — the _noop fix in the V1 prepare path (#36221) covers the V1 session/compaction flow, but the V2 session runner may have an analogous gap.

In packages/core/src/session/runner/llm.ts, the last step (when currentStep >= agentInfo.steps) builds the request with:

tools: toolMaterialization?.definitions ?? [],   // [] on the last step
toolChoice: isLastStep ? "none" : undefined,

toLLMMessages(context, …) preserves ToolCallPart/ToolResultPart blocks from prior steps, so the messages sent on the last step still contain tool history. Meanwhile the Bedrock Converse protocol (bedrock-converse.ts) omits toolConfig entirely when toolChoice.type === "none":

const toolConfig =
  request.tools.length > 0 && request.toolChoice?.type !== "none"
    ? { tools: lowerTools(…), toolChoice }
    : undefined

So on the last step Bedrock receives messages with toolUse/toolResult blocks but no toolConfig. If Bedrock requires toolConfig whenever messages contain tool history (which is what this issue reports for the V1 path), the V2 runner would hit the same toolConfig field must be defined error on the last step for Bedrock-backed models.

I can't confirm without testing against a live Bedrock endpoint — it's possible Bedrock accepts tool-history messages without toolConfig when no toolChoice is sent. But if it doesn't, the V2 runner needs the same _noop injection (or the protocol needs to send a minimal toolConfig) when tools are empty but the history contains tool calls.