- Consolidate Phase 7a (FileLockManager), 7b (LockGuardedToolExecutor + tool runner integration), and 7c (persistent background task history) into single branch
- Wire background task clicks in History view to open the read-only BackgroundTaskReplayView instead of creating a resumable task
- Add StandardTooltip on interrupted background tasks explaining they were interrupted due to VS Code closing
- Add interruptedTooltip i18n key across all locales
- Add tests for replay view routing and tooltip rendering
Addresses feedback from #12330
- Add background field to HistoryItem schema
- Add interrupted status for background tasks stopped mid-execution
- Add background option to TaskMetadataOptions
- Detect and mark interrupted background tasks on TaskHistoryStore init
- Add showBackgroundTasks filter to useTaskSearch hook
- Add background task filter toggle to HistoryView UI
- Add background/interrupted visual indicators in TaskItemFooter
- Add i18n translation keys for background task labels
- Add unit tests for all changes
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>
