- Use base provider convertToolSchemaForOpenAI() for tool schema hardening
- Handle MCP tools with isMcpTool() (strict: false for MCP, true otherwise)
- Respect metadata.tool_choice instead of always using "auto"
- Add parallel_tool_calls pass-through from metadata
- Fix assistant string content to use output_text format (not input_text)
- Remove unused modelInfo param from createUsageNormalizer
- Add cacheWriteTokens extraction to usage normalizer
- Fix test() -> it() inconsistency in xai.spec.ts
- Update tests to match all changes
Migrate the xAI provider from the deprecated Chat Completions API to the
Responses API, add grok-4.20 as the new default model, and introduce shared
transform utilities for Responses API that other providers can adopt.
New shared utilities (src/api/transform/):
- responses-api-stream.ts: processResponsesApiStream() handles core
Responses API stream events (text, reasoning, tool calls, usage) and
createUsageNormalizer() provides configurable token/cost extraction.
Designed for reuse by openai-native, openai-codex, or any future
Responses API provider.
- responses-api-input.ts: convertToResponsesApiInput() converts directly
from Anthropic message format to Responses API input format, avoiding
the intermediate Chat Completions conversion step. Handles input_text,
input_image, function_call, and function_call_output mappings.
xAI provider (src/api/providers/xai.ts):
- Switch from client.chat.completions.create() to client.responses.create()
- Use shared transform utilities for stream handling and input conversion
- Enable reasoning traces via include: ["reasoning.encrypted_content"]
- System prompt via instructions field, store: false for privacy
- completePrompt() also migrated to Responses API
Model updates (packages/types/src/providers/xai.ts):
- Add grok-4.20 as the new default model (2M context, $2/$6 pricing)
- Remove grok-4.20-beta-0309-reasoning and grok-4.20-beta-0309-non-reasoning
feat(bedrock): add Cohere Embed v4 model and improve credential handling
- Add cohere.embed-v4:0 (1536-dim) to Bedrock embedding model profiles
- Add v4-specific request format (embedding_types: ["float"]) and response
parsing (embeddings.float[0]) in BedrockEmbedder
- Replace fromEnv() with fromNodeProviderChain() for default credential
chain when no AWS profile is specified, supporting SSO, IMDS, ECS, and
other credential sources with built-in memoization
- Add unit tests for Cohere v4 request/response handling, credential
provider selection, and v3 regression coverage
Fixes#11823
feat(cli): add create-with-session-id support
rename public task id flag to --create-with-session-id
validate session ids as UUIDs for create/resume and stdin start.taskId
add integration coverage for create+resume loading correct session
* Allow selecting a specific shell
Add --terminal-shell CLI flag to specify which shell ExecaTerminalProcess
uses for inline command execution. The shell path is validated at the CLI
layer and passed through the standard settings mechanism (BaseTerminal
static getter/setter), matching how all other CLI terminal settings flow
through the system.
* test(cli): make shell path access test cross-platform
In CLI runtime, stdin harnesses expect command lifetime to be governed
solely by commandExecutionTimeout (user setting), not model-provided
background timeouts. Extract resolveAgentTimeoutMs() and return 0 when
ROO_CLI_RUNTIME=1.
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
feat(cli): support images in stdin stream start and message commands
Add optional `images` field (array of base64 data URIs) to the `start` and
`message` CLI stdin stream commands, allowing callers to attach images to
prompts. The images are validated, forwarded through the extension host, and
included in queued messages.
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
Propagate the command exit code through the JSON event emitter so CLI
consumers can distinguish between successful and failed command
executions without parsing output text.
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
fix: forward task configuration through stdin-prompt-stream protocol
The stdin-prompt-stream `start` command only accepted `prompt` — any
`configuration` passed via the cloud worker's StartNewTask was silently
dropped. This meant custom modes (e.g. `ask-artifacts`), disabled tools,
and other task-level settings never reached the extension when running
via the CLI harness.
Changes:
- Add optional `configuration` field to the `start` stdin command
- Parse and forward it in `runStdinStreamMode`
- Thread it through `ExtensionHost.runTask` → `newTask` webview message
→ `ClineProvider.createTask` (which already calls `setValues`)
- Add `taskConfiguration` field to `WebviewMessage` type
Backward-compatible: older CLIs ignore the extra field; older workers
that don't send `configuration` trigger no change in behavior.
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Co-authored-by: cte <cestreich@gmail.com>
