[FEATURE] Worker thread isolation for in-process subagents and teammates

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

All in-process teammates and subagents share a single Node.js event loop with no worker thread isolation. CPU-bound operations in one agent block all other agents until completion.

For a software development tool, CPU-heavy operations are routine:

• Parsing large file contents returned from the Read tool
• Processing grep/glob results across large codebases
• Serializing/deserializing conversation history for API calls
• Processing tree-sitter parsing results (WASM modules are bundled)
• String manipulation on large tool outputs

When multiple in-process teammates are active, any of these operations in one teammate stalls all others. The impact grows with team size and codebase complexity.

While the API call latency currently dominates wall-clock time, this balance will shift as models get faster and agent teams encourage more parallelism.

Proposed Solution

Use Node.js worker_threads to give each in-process subagent/teammate its own execution thread:

• Each subagent/teammate runs in its own Worker
• The main thread handles coordination, hooks, UI, and message routing
• Workers receive a serialized copy of settings/config at startup
• Tool results pass back via postMessage or SharedArrayBuffer
• The hook system remains on the main thread for consistency

This provides true parallelism for CPU-bound work while maintaining the process-level simplicity of in-process mode (no tmux dependency, works on Windows).

Alternative Solutions

• Pane-based mode (tmux/iTerm2): Already provides process isolation, but is unavailable on Windows, doesn't support parent-process hooks (see #24175), and has higher overhead per teammate.
• Accepting the status quo: Works for small teams and small codebases where API latency dominates. Degrades as team size or codebase complexity grows.
• Async yielding: Cooperative multitasking by breaking CPU-heavy operations into smaller chunks with setImmediate. Reduces blocking but doesn't provide true parallelism and requires changes throughout the tool execution pipeline.

Priority

Medium - Would be very helpful

Feature Category

Performance and speed

Use Case Example

1. A team lead spawns 4 in-process teammates to work on different parts of a large monorepo
2. Teammate A runs a codebase-wide grep that returns 50MB of results and begins processing them
3. Teammates B, C, and D all have API responses waiting to be processed
4. Currently: B, C, and D are blocked until A finishes parsing its grep results
5. With worker threads: A processes in its own thread while B, C, D proceed independently on theirs

Additional Context

Verified by reading cli.js (v2.1.37):

• No worker_threads, Worker, parentPort, or workerData usage found anywhere in the codebase
• In-process teammates run via async generators on the main event loop (xj6() → SPY() → LR())
• Parallel tool calls within a single agent use Promise.allSettled() — concurrent but still single-threaded
• The bundled native ripgrep module (ripgrep.node) and tree-sitter WASM modules suggest performance is already a design concern — worker threads would extend this to the agent execution layer