Advisory file-level locking so concurrent tasks coordinate write access safely.
- FileLockManager class with acquire/release/releaseAll operations
- Per-file locks with automatic expiration (configurable timeout, default 2min)
- Re-entrant lock support (same task can re-acquire its own lock)
- Lock conflict detection with detailed conflict info
- Event system for lock lifecycle (acquired/released/expired)
- Reverse index for efficient per-task lock lookup
- Path normalization for consistent lock keys
- 39 comprehensive unit tests covering all operations
Part of Phase 7 (Controlled Write Parallelism) for Issue #12330
Adds a collapsible Background Tasks Panel to the chat sidebar that shows
active and recently completed background tasks. This builds on the Phase 4
BackgroundTaskRunner to give users visibility into background work.
Key changes:
- BackgroundTaskStatusInfo type for exposing task status to the webview
- BackgroundTaskRunner tracks completed tasks with result summaries
- BackgroundTaskRunner.getTasksStatus() returns combined active + completed
- BackgroundTaskRunner.onStateChanged callback for UI refresh
- backgroundTasks field added to ExtensionState and getStateToPostToWebview
- cancelBackgroundTask webview message handler
- postBackgroundTasksToWebview() for lightweight status-only updates
- BackgroundTasksPanel React component with collapsible panel, cancel
buttons, active count badge, and result summaries
- 31 backend tests (BackgroundTaskRunner) + 7 UI tests (panel component)
- Add BackgroundTaskRunnerCallbacks interface with onTaskTimeout and onTaskError
- Wire VS Code notifications in ClineProvider: info on completion, warning on timeout/error
- Document auto-approval design decision for read-only background tasks
- Add 2 new tests for callback invocation (19 total, all passing)
Implements the MVP for Phase 4 of the parallel execution roadmap:
- Add BackgroundTaskRunner service that manages concurrent read-only
background tasks separately from the clineStack
- Add isBackgroundTask flag to Task class that suppresses webview
updates and auto-approves all tool uses
- Extend new_task tool with optional background parameter
- Background tasks are restricted to read-only tools only
- Results are delivered asynchronously to the parent task via
onBackgroundComplete callback
- Configurable concurrency limit (default 3) and timeout (default 5min)
- Proper cleanup on task cancellation, parent cancellation, and
provider disposal
- 17 new tests for BackgroundTaskRunner, all existing tests pass
Issue #12330
1. Persist taskPermissions in HistoryItem so permissions survive task
restarts. Added taskPermissions field to historyItemSchema, included
it in taskMetadata output, and restored it in the Task constructor
when loading from history.
2. Add ReDoS mitigation for model-provided regex patterns:
- isSafeRegex() heuristic rejects nested quantifiers like (a+)+
and overlapping alternations in repeated groups like (a|a)+
- Max pattern length capped at 200 characters
- Both checks enforced at schema validation time via Zod refinements
- 11 new tests covering ReDoS detection and persistence round-trips
1. Anchor regex patterns in matchesAnyPattern with ^(?:...)$ wrapping so
patterns like "src/.*" require full-path matching instead of substring
matching. Prevents "evil/src/foo" from matching a "src/.*" permission.
2. Add regex validation at schema level (regexString refinement) so
invalid patterns are rejected at parse time rather than silently
failing at runtime.
3. Simplify duplicate file/command pattern validation in validateToolUse
by unifying layered and flat code paths into a single branch that
falls back to wrapping flat patterns as a single layer.
4. Remove unused matchesAnyPattern import from validateToolUse.ts.
5. Add tests for anchoring behavior, pre-anchored patterns, and
invalid regex rejection at schema level.
1. NativeToolCallParser: Remove permissions from update_todo_list cases
(was erroneously added to wrong tool case, should only be on new_task)
2. deniedTools: Exempt ALWAYS_AVAILABLE_TOOLS (attempt_completion, etc.)
from deniedTools check, matching the existing allowedTools behavior.
Prevents parent from trapping subtask by denying completion tools.
3. Pattern merging: Replace broken exact-string intersection with layered
enforcement. filePatterns/commandPatterns from parent and child are
kept as separate layers (AND between layers, OR within each layer).
This correctly handles narrowing: parent ["src/.*"] + child
["src/components/.*"] now allows only files matching BOTH patterns,
instead of producing an empty intersection.
Adds an optional `permissions` parameter to the `new_task` tool, allowing
the Orchestrator (or any parent task) to dynamically set permission
boundaries for subtasks:
- New `TaskPermissions` type with filePatterns, commandPatterns,
allowedTools, and deniedTools
- Permission merging with most-restrictive-wins semantics for nested
subtask delegation
- Runtime enforcement in validateToolUse() for all permission types
- Full test coverage for merging logic and enforcement
Addresses Issue #12330 (Phase 3b)
Introduces the foundation for isolated task execution (Phase 3a of #12330):
- TaskContext: immutable snapshot of mode, API config, and workspace for
each task, replacing runtime reads from shared ClineProvider state
- TaskPermissions: fine-grained permission boundaries (file patterns,
command restrictions, read-only mode, tool allowlists) that the
orchestrator can attach when spawning subtasks
- TaskContextBuilder: factory functions to build TaskContext from provider
state and to derive child contexts with merged permissions
- Task constructor now accepts optional taskContext, using it for mode
and API config initialization instead of provider.getState()
- delegateParentAndOpenChild builds and passes a TaskContext to child tasks
- Permission merging follows most-restrictive-wins semantics
This is a pure refactor with no behavioral change -- tasks still execute
sequentially, but they now carry their own isolated context. Enforcement
of permission boundaries is deferred to Phase 3b/3d.
Ref: #12330
- Fix off-by-one: dispatch subtaskQueue[currentIndex] instead of
subtaskQueue[nextIndex], preventing the first queued item from being
skipped
- Fix completedMode: fetch child history to get the child actual mode
instead of incorrectly using the parent historyItem.mode
- Update tests to reflect corrected queue semantics (subtaskQueueIndex
represents the next item to dispatch, not the currently running item)
Adds subtask queue support to the new_task tool, allowing the orchestrator
to define multiple subtasks that execute automatically in sequence without
returning to the parent between each one. This saves LLM API calls and
enables more efficient multi-agent workflows.
Key changes:
- SubtaskQueueItem, SubtaskResult types in packages/types/src/history.ts
- task_queue parameter on new_task tool (optional JSON array)
- NewTaskTool parses and validates queued subtasks, stores on parent
- delegateParentAndOpenChild persists queue in parent HistoryItem
- reopenParentFromDelegation auto-advances queue via advanceSubtaskQueue
- formatAggregatedQueueResults aggregates all results when queue completes
- 9 new tests covering queue advance, exhaustion, and result formatting
- All 56 existing delegation tests continue to pass
Phase 1 of #12330 - improves context handoff visibility between
parent and child tasks during delegation.
Changes:
- Add SubtaskSummary type to @roo-code/types for structured handoff data
- Create buildSubtaskSummary utility that extracts files modified/read,
commands executed, tool usage, and todo stats from task history
- Modify AttemptCompletionTool to build structured summary on completion
- Update reopenParentFromDelegation to format enriched API history text
so the parent LLM gets better context about what the subtask did
- Update ChatRow UI to render structured summaries with mode badge,
file lists, command lists, and todo progress
- Add i18n translation keys for new UI elements
- Add 19 tests for buildSubtaskSummary and formatSubtaskSummaryForApi
- Backward compatible: plain-text summaries still work as before
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
* 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>
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>
* fix(cli): streaming deltas, task ID propagation, cancel recovery, and misc fixes
- Stream tool_use ask messages (command, tool, mcp) as structured deltas
instead of full snapshots in json-event-emitter
- Generate task ID upfront and propagate through runTask/createTask so
currentTaskId is available in extension state immediately
- Wait for resumable state after cancel before processing follow-up
messages to prevent race conditions in stdin-stream
- Add ROO_CODE_DISABLE_TELEMETRY=1 env var to disable cloud telemetry
- Provide valid empty JSON Schema for custom tools without parameters
to fix strict-mode API validation
- Skip paths outside cwd in RooProtectedController to avoid RangeError
- Silently handle abort during exponential backoff retry countdown
- Enable customTools experiment in extension host
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* fix: add start() to TaskStub in single-open-invariant test
The ClineProvider.createTask change to call task.start() after
addClineToStack requires the test's TaskStub mock to have this method.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
* changeset version bump
* Revise CHANGELOG for recent version updates
Updated changelog for versions 3.50.4 to 3.48.0, including new features, fixes, and improvements.
---------
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: Matt Rubens <mrubens@users.noreply.github.com>
* feat: add MiniMax M2.5 model and set as default
* fix: update MiniMax M2.5 contextWindow to 204_800
* Delete .changeset/add-minimax-m25.md
---------
Co-authored-by: Roo Code <roomote@roocode.com>
Co-authored-by: Matt Rubens <mrubens@users.noreply.github.com>
