When a terminal is created with conda auto-activation (or any shell
initialization that runs commands), a race condition could occur where
VSCode fires onDidStartTerminalShellExecution events for BOTH the conda
activation AND Roo's command. The previous implementation blindly set
the stream when the event fired, causing Roo to pick up the wrong stream
and miss its own command's output.
This fix:
1. Adds an optional eventCommand parameter to setActiveStream()
2. Passes the command from the shell execution event for verification
3. Only emits stream_available if the event command matches Roo's command
4. Uses flexible prefix matching to handle PowerShell workarounds
Fixes#11148
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>
