Qwen Code contributions

Web Shell lists standalone sessions in its sidebar. The daemon refuses to delete a session with an active prompt or attached client; its batch deletion route reports a per-session session_busy error inside an HTTP 200 response.

The earlier #12636 change disabled Delete for the current row. Its maintainer left the alternative of leaving first and then deleting for follow-up Issue #12669. The current tab can detach, but another tab may still be attached to the same session.

On the unmodified source baseline, the current standalone row displayed Delete but kept it disabled. Simply enabling the button would send deletion while this tab was still attached and receive session_busy from the daemon.

A normal New task result did not prove that detach succeeded: clearSession swallowed detach errors, and the SDK treated a missing clientId as a no-op. Sidebar list counts could also lag behind the live state.

Upstream review of the first PR version found a separate Critical: while asynchronous detach or deletion ran, Cancel and other close controls could dismiss the confirmation dialog even though deletion would continue.

The client lacked an ordered operation for the current row: confirm deletion, leave the exact original session, prove that detach finished, then request deletion of that fixed ID. The daemon's busy guard was correct and must remain in place.

The existing callback discarded the result of New task, while the ordinary clearSession path could hide detach failure. Neither was suitable as the prerequisite for a destructive delete request.

Both sidebar Delete entrances now allow an idle current standalone row to reach the existing confirmation dialog. The action rechecks the live App state and original session ID at confirmation; running work remains protected.

A deletion-only awaitable callback reuses createNewSession({ kind: 'global' }) with strict clearSession checks. It requires the expected session ID and matching nonempty clientId values, reports detach failure, and waits for detach before sending batch deletion for the fixed original ID.

Only removed or notFound removes the row. A per-item session_busy or request failure leaves it visible and reports the error; after leaving, the list is refreshed. The daemon busy guard and the separate /delete selector remain unchanged.

After upstream review, I disabled every dialog close entrance during the operation and added a synchronous busy guard to onClose. The confirmation remains visible while detach or deletion is pending.

Following the review's suggestions, commit a2b39eb405 shows progress while deletion runs (Deleting... with aria-busy), keeps Delete disabled until the session is attached and ready, gives one message for a failed leave or a cancelled navigation, removes a dead branch around an optional callback, and adds regression tests for retry, refresh and strict detach. The English and Chinese design notes were updated to match.

The daemon preheats a separate ACP child process at startup so the first session does not pay cold-start cost. The consequence is a window in which the daemon is already serving HTTP and WebSocket traffic while the child is still parsing argv and initialising its configuration.

ProcessRegistry tracks every child the daemon spawns and is responsible for proving at shutdown that they are all gone. The ACP child is spawned detached and becomes its own process group leader, so signalling the negative process group identifier reaches the whole tree at once.

Since #10140 the shutdown contract is deliberately strict: the daemon exits non-zero unless it can prove both that the child exited and that its process group no longer exists. Relaxing any branch of that proof is a safety-relevant change, which is why this cannot be routed through automatic fixing.

On macOS with Node.js v26.8.2, sending SIGTERM to the daemon before preheat finished made it exit 1. The persistent log contained could not send SIGKILL to pgid, ACP child process shutdown failed and daemon shutdown incomplete — yet ps, the process group query and lsof all confirmed afterwards that nothing was left behind.

Instrumentation showed the sequence. The group SIGTERM succeeded; roughly two milliseconds later the preheat abort issued a synchronous kill; at that moment the child had already exited but Node had not yet delivered its exit event, so the group SIGKILL returned EPERM. The exit event then arrived and the whole group disappeared. A minimal detached-child Node probe reproduces the same kernel and runtime visible timing.

This was first seen while verifying #12277, so it was checked against an isolated build of the unmodified official commit with no Local Control call at all. The same EPERM and the same exit 1 appeared, which ruled out the port fix as the cause and made this a separate report rather than a regression of that branch.

The group signalling path drops a process group only on ESRCH; every other errno is written into the cleanup proof error with a nullish assignment, so the first error is latched for the rest of the child lifetime and there is no reset anywhere in the file. The clean path then throws that latched error before it ever reaches the unclean-exit decision, so one transient error is enough to turn a completely clean shutdown into a non-zero exit.

The file contradicts itself. The surviving-groups helper tolerates EPERM fifteen lines below the signalling path that treats it as fatal, and the direct child kill swallows every error. The same EPERM is ignored when it arrives from one call and fatal when it arrives from the other, while the repository-wide convention sits on the tolerant side: the process liveness helper reads EPERM as positive evidence that a process is alive.

A second, independent cause sits in the child. The full ACP signal handler is installed late, so a SIGTERM arriving during startup takes the default action and the child dies by signal. The parent strict contract then correctly calls that unclean. Fixing only the first cause left the daemon still exiting 1 with exited uncleanly during shutdown, which is how the second layer was found rather than assumed.

The group signalling path now holds EPERM provisionally per process group instead of latching it globally. When a later liveness check or the process table proves that group is gone or contains only zombie and terminal entries, both the group and its provisional error are forgotten. If a live member survives to the ten-second deadline, the original EPERM is retrieved and included in the failure. Every other errno stays fail-closed.

The child installs its signal handling in three stages with synchronous handoff: a minimal handler at the CLI bundle entry, a startup handler that runs the generic cleanup once the main flow begins, and the full managed ACP handler once session, writer, MCP and transport state exist. Each stage installs the new handler before removing the old one, so there is no listening gap.

If a signal arrives before the handoff completes, the pending shutdown is passed to the full handler, and the older cleanup promise is prevented from exiting the process directly so that writer, session and MCP cleanup is not skipped. The new path is gated on an exact ACP flag plus the daemon stamp and a daemon-private parent capability, so plain command-line use, editor-driven ACP and the parent strict unclean-exit judgement are untouched.

qwen serve runs a background daemon that listens on 127.0.0.1 only. Local Control lets a phone on the same network reach it, not by widening the primary listener, but by opening a second HTTP listener on a selected LAN IPv4 address inside the same process, serving the same Express application.

The two entrances must authenticate differently. The primary listener accepts the daemon runtime token, which carries full API access including code execution; the LAN listener accepts only a single-use pairing token delivered in a URL fragment and encoded as a QR code. Which listener a request arrived on is what separates the two privilege levels, so the authority and origin recorded on each listener feed both the HTTP Host check and the WebSocket Origin check.

TCP binds a pair of address and port, so 127.0.0.1:51873 and 10.131.53.163:51873 are normally two distinct endpoints — which is why reusing the primary port number looked safe. A collision happens only when that LAN endpoint itself is held, and --port 0 makes it plausible: the operating system draws ephemeral ports from the same pool that every outbound TCP connection uses for its source port.

On the unmodified source baseline, and independently on the published npm 0.24.1 package, holding the LAN endpoint with a temporary socket and then posting to the Local Control enable route returned HTTP 500 with code local_control_enable_failed. The underlying error was listen EADDRINUSE: address already in use 10.131.53.163:51873.

The daemon log recorded only that the request returned 500, never the EADDRINUSE reason, because the runtime error log handler is installed only after the first successful bind. A user saw a failure with no diagnosable cause, and state was left correct but unusable: active false, with no stray Local Control listener.

Releasing the holding socket and re-sending the identical request returned 200, and lsof then showed one daemon listening on both 127.0.0.1:51873 and 10.131.53.163:51873. That confirms the same port number on two local addresses is normally fine, and that the primary listener was not itself the source of the collision.

LocalControlService computed the LAN endpoint before binding. It read the primary daemon port, built the authority, origin and pairing URL from it, registered the listener identity and credentials, and only then called listen on that same port. Port choice and endpoint metadata were coupled.

Because the metadata is generated ahead of the bind, changing only the port passed to listen would leave the pairing URL, CORS origin, listener identity and the reported status pointing at the old endpoint. That would either admit requests that should be refused or lock out the very phone the pairing URL was issued to.

The failure path did unwind the temporary state correctly, but it had no port retry, and the error never reached persistent logging. The route mapped everything that was not a known interface or target error to a single generic 500 local_control_enable_failed.

The LAN listener still prefers the primary port and falls back exactly once to port 0, and only when the error is a typed EADDRINUSE. Every other errno still fails, so a permission or address problem is not hidden behind a blind retry.

Both the normal and the fallback path now derive the endpoint unconditionally inside the synchronous listening callback from server.address(), which removed the earlier design where the normal path pre-computed metadata before binding. Authority, origin, pairing URL, listener identity and the reported status are all filled from the port actually obtained. During a fallback the old origin is removed first and the listener is marked as Local Control without an authority, so the Host gate refuses by default until the new identity is registered.

Final bind failures map to actionable codes — 409 address_in_use, 403 bind_denied and 409 invalid_address — instead of one opaque 500, and the existing DaemonLogger is injected so both the fallback and the final failure reach the persistent log. Log calls are wrapped so a failing log sink cannot roll back a listener that is already up, and neither the runtime token nor the pairing token is written to the log.

The Web Shell editor represents a selected file reference as a CodeMirror inline tag with a known [start,end) range. Submission serializes the tag into prompt text; UserMessage uses inputAnnotations to draw the selected reference as a chip.

A user can type the same serialized text manually. Matching text alone cannot distinguish that ordinary text from a reference selected through the file picker.

In literal @foo then [foo], the editor correctly treated the second @foo as a chip. After submission, its annotation covered [8,12), the earlier plain text, instead of the selected chip's [18,22). The message therefore misrepresented the user's selection.

My component reproduction kept the raw prompt string unchanged. It proved the annotation and UI mismatch, without establishing a change in model input or file resolution.

Submission used the editor's real inline placements to serialize the prompt, but then discarded those ranges when creating inputAnnotations. The annotation helper searched from the start with indexOf(serialized, cursor), so an earlier identical string claimed the chip's annotation.

The rendering check only compared annotation text with its referenced substring. Both occurrences contained @foo, so this check accepted the wrong location.

I traced the source, reproduced the real CodeMirror editor, submission hook and UserMessage together, checked related upstream reports, and filed #12980 using the bug-report template. I submitted no product patch.

Maintainer yiliang114 authored #12992 to pass real chip placements into annotation generation, accounting for prompt prefixes and shell mode. Review led to additional regressions and a fallback that matches serialized text only when it is globally unique if a custom provider's placement no longer matches.

At ordinary startup, Qwen Code selects agent worktrees whose root directory mtime is over 30 days old and that appear to have no user work. Edits inside a subdirectory need not refresh that root mtime. Before the fix, its documentation said user-named worktrees were never automatically cleaned.

The user-facing enter_worktree path and agent isolation share a creation API that permits an exact agent-<7hex> name, so the directory name does not prove who created the worktree.

Before the fixes, a user-named worktree with an agent-<7hex> name and a root directory mtime over 30 days old could be selected for cleanup when it had no tracked changes or branch-only commits.

The cleanup then removed the worktree with force. Untracked files are outside Git history, so their deleted contents could not be restored from Git.

The same blind spot could also expose genuinely agent-created worktrees containing new files. That broader risk followed from the source path; the executed reproduction used a user-named worktree.

The cleanup treated the directory naming pattern as proof of agent origin, although the user worktree validator permitted the same name. No persistent origin marker was added by the fixes.

Before the fixes, its dirty check ran git status --porcelain --untracked-files=no, so a new file was invisible to that check; git worktree remove --force then deleted it.

I traced the source path, ran the actual cleanup function in a disposable Git repository, searched for duplicate upstream reports, and filed #12735 using the project's bug-report template. I did not change product code.

The maintainer authored both merged PRs. PR #12763 primarily addressed neighbouring Issue #12758 and introduced a shared content check covering untracked and non-exempt ignored files; PR #12739 added real Git regression tests, preservation logs and documentation for #12735. Neither PR contains code I submitted.

Pull requests to Qwen Code are reviewed by an AI review bot. Each finding it posts starts with a severity marker written as plain text: **[Critical]** for a must-fix problem, **[Suggestion]** for something optional. There is no separate severity field; the marker at the top of the comment is the only signal.

Autofix is a GitHub Actions workflow (qwen-autofix.yml) that takes over a pull request and pushes fixes for that feedback round after round. To stop a pull request from growing endlessly on optional ideas, it switches to Critical-only mode from the sixth round, or earlier once the diff grows past a budget. From then on only Critical findings, formal change requests, failing checks and merge conflicts may make it change code; suggestions are recorded as deferred and left for people. The workflow reads each comment’s severity with jq, a command-line tool for JSON, so a text match decides what the bot does next.

Review comments quote evidence to prove a finding — test output, logs, a diff — pasted into a code block. PR #9740, merged on 28 Aug, extended that rule to suggestions: a suggestion now has to quote its evidence too. The review feature’s own tests print the literal text **[Critical]**, so from then on that text regularly appeared inside suggestions as quoted evidence.

Issue #10216 was opened by the Autofix loop itself. While working on #9740 it confirmed this misclassification, but the fix lay in qwen-autofix.yml: outside that pull request, and a file the loop is not allowed to edit. It deferred the finding to an issue for a person to fix. The design note docs/design/review-tone.md had already listed the same repair as a possible follow-up.

A proper suggestion starts with **[Suggestion]** but may quote **[Critical]** inside a code block of test output. The quoted text is evidence, not the comment’s own severity, yet the old workflow searched the whole body for it: twelve places in the workflow and four in its verification script used a position-independent contains("**[Critical]**").

In Critical-only mode that turned the suggestion into a must-fix item. The bot could then change code for it, which is exactly what Critical-only mode exists to prevent, while the suggestion vanished from the deferred list that tells people what was left open, and the per-author feedback budget was counted wrongly.

Replies made it worse. A reply in an inline thread takes its classification from the first comment of the thread, so a suggestion that quoted the marker also made the replies under it look like blockers, although neither was one.

This was one text test repeated sixteen times, not a single typo. Three parts of the workflow use the result — what the fixing agent is asked to do, the deferred list, and the per-author budget count — and each reads four kinds of comment: a review, the first comment of an inline thread, the parent of a reply, and an issue comment. Fixing one place would have left the workflow disagreeing with itself.

The new rule looks only at the start of the comment’s source text, after skipping leading whitespace, HTML comments and invisible Unicode formatting characters. It deliberately does not treat every HTML tag or entity that might render as blank as invisible, and the documentation now states that narrower rule instead of claiming to judge the rendered text.

#9740 also told the review bot to neutralise markers inside quoted evidence. That reduces new cases but cannot fix old comments, other bots, maintainers or future tools that write comments. The safe place for the rule is where the workflow reads the signal, while real Critical comments, and the replies that rightly inherit from them, keep working.

All sixteen checks now follow one rule — a marker counts only if it leads the comment — written once in each of the nine self-contained jq programs that hold them: seven in the workflow and two in the verification script. A marker quoted later in the body no longer changes the severity; a real Critical at the start still does.

The code that writes review comments got a matching safeguard. When a comment that still carries a Critical finding has an opening line, a budget note or a downgrade notice put in front of it, a short visible Critical heading is added at the top, so the comment still passes the stricter check.

Tests pull the real jq programs out of the YAML and shell files and run them against sample comments: quoted evidence, direct comments, thread and reply inheritance, the deferred list and the budget count. The later commits share one quoted-Critical sample across the tests, change the over-budget notice from “tag **[Critical]**” to “start your comment with **[Critical]**”, and bring the design note review-tone.md, the Autofix notes and the review bot’s posting instructions in line with the new rule, with a test that stops the old wording from coming back.

In Qwen Code the model gets work done by calling tools: it names a tool and passes JSON arguments, the program runs it, and the result goes back to the model. send_message is one of these tools. The main agent — the model itself, not the user — uses it to send a follow-up instruction to another agent. The recipient treats it as work and may go on to edit files or run commands, so a message that reaches the wrong agent is not a cosmetic mistake.

The main agent can direct two kinds of agents, and both run in the background alongside it. Both are started with the same Agent tool; the only difference is whether a name is passed. Without a name, the tool starts an anonymous agent for a single job and records it in the background-task registry (BackgroundTaskRegistry). With a name, once team_create has set up a team, it adds a long-lived teammate such as qa-reviewer to the team roster kept by TeamManager.

The two kinds never overlap. A teammate is never entered in the background-task registry, so it has no task_id, and list_agents does not show it. An anonymous background agent has no name that to could reach. No agent holds both addresses, so a correct call fills exactly one of the two fields.

The name task_id is misleading. It is not a work-order number that still needs a recipient: it is the number of the agent itself, returned when the agent starts, in the form general-purpose-<suffix>. A background agent exists for one job, so the job’s number and the agent’s number are the same thing. The team does keep real work items with owners, in its shared task_list, which puts the word “task” on the teammate side as well.

Before the fix, the tool accepted both fields in one call and checked task_id first; to was read only when task_id was empty. This was never a stated rule, just the order of an if/else with no check for both being set. So if a call carried to: "qa-reviewer" and a real task_id, the message went to the background agent, the tool reported success, and qa-reviewer got nothing. Nothing said the message had gone astray. The agent that did receive it treated it as work, and if it had already finished, the message started it up again.

If the task_id did not match, the call failed with “No background task found”, and to was ignored even when it was right. That includes a call with qa-reviewer in both fields, which is a natural thing to write if you assume the two fields describe the same agent.

A teammate’s name in task_id always fails, because teammates are never in the background-task registry. The error was true but pointed the wrong way: it spoke only of background tasks, said nothing about teammates and offered no next step. To the model it even looks contradictory, since qa-reviewer really is running in the background, and checking list_agents does not help because teammates are not listed there. The model might retry, decide the teammate is gone and do the work again, or drop the instruction. The report does not show any of these follow-on steps; they are what the code allowed, not what was observed.

The JSON schema required only message and left both recipient fields optional. The code expressed a priority — task_id first, then to — but never the rule that actually has to hold: a valid call picks exactly one of the two.

When the registry lookup missed, the method returned at once. It never asked whether the value was a teammate’s name, although TeamManager already held the roster and the rules for matching names.

A maintainer’s end-to-end run with the real CLI found a second gap. The test helper could read llmContent and returnDisplay directly, but for a failed tool call CoreToolScheduler passes error.message to the model. The hint was computed correctly yet never reached the model until it was written into that field as well.

The rule could not simply go into the schema. send_message itself once used a top-level oneOf to require one of the two fields, and that made the whole tool unusable on Anthropic models (#7984), so oneOf was removed. The check has to happen at run time.

The check for both fields goes in validateToolParamValues, the validation hook every tool has. It runs before the call is created, so an ambiguous call ends as INVALID_TOOL_PARAMS before the scheduler, the task queue or TeamManager can deliver anything.

Only after BackgroundTaskRegistry finds no task does the tool look at the current team. It reuses the existing findMemberByName helper, so "QA Reviewer" still resolves to the canonical qa-reviewer, and it suggests to only when the roster really has that member.

The last production change was one line: when that match exists, the existing hint is appended to error.message, the field CoreToolScheduler actually passes to the model. The schema sent to model providers, the SEND_MESSAGE_NOT_FOUND error type, the queue and TeamManager’s delivery are unchanged, and an unrelated unknown task ID still gets its original error word for word.