Qwen Code Preview Advances Multi-Agent Workflows with an Observable, Isolated Environment for Long-Running Tasks

Qwen Code released version 0.23.1-preview.2 on September 7. Rather than replacing the underlying model, the update focuses on strengthening the execution control plane required for multi-agent coding. The new Web Shell can display and manage dynamic workflows, return a run handle for each execution, and update sub-agent status in the conversation history. The server also adds a session resource directory and a cross-turn navigation protocol, so the frontend no longer has to infer solely from linear chat text which resources an agent currently holds or how far it has progressed.

For isolation and consistency, named tasks can now be configured with dedicated Git worktrees, reducing conflicts when multiple agents modify the same working directory simultaneously. A conversation writer must acquire a session lease before writing, while IPC explicitly notifies senders when messages are rejected, assigns expiration times to buffered messages, and allows repository-level settings to tighten—but not relax—inbound policies. These mechanisms cannot guarantee that agents produce correct code, but they address engineering failures that are more common in long-running executions: stale messages, duplicate writes, cross-session message leakage, and loss of visibility into background agents.

The release also adds a workspace-scoped Skills runtime, a browser-authorized bridge to local directories, and optional display of tool parameters. Security-related fixes include preventing the DingTalk channel from logging client secrets and rejecting ambiguous `send_message` destinations. The full changes are available in the [GitHub release notes](https://github.com/QwenLM/qwen-code/releases/tag/v0.23.1-preview.2), while third-party summaries also identify workflow visibility and isolation as the release’s main advances.

Engineering teams should still treat it as a preview. Qwen has not published long-running task success rates, workflow recovery rates, concurrency limits, or compatibility test results against the stable release. The update also introduces a large number of features and refactors at once, including the retirement of the legacy WebUI. Key areas to watch next include whether ownership can be transferred reliably after a lease expires, how worktree merge conflicts are handled, and whether workflow and Skills permissions implement an auditable least-privilege model.