Qwen Code Reverts ACP Memory Commands One Night After Shipping Them

On June 7, Qwen Code shipped ACP-mode support for /remember, /forget, and /dream. On June 8, they reverted it. The headline commit in v0.17.1-nightly.20260608.aea34fa2c reads: "Revert 'feat(cli): enable /remember, /forget, /dream in ACP mode (#4811)' (#4818)". That is the most useful kind of release note — an honest acknowledgment that a boundary was not ready. Most teams do not ship that admission in a changelog.

The reverted PR #4811 had exposed memory commands in both interactive and ACP modes, but it also documented a runtime mismatch: /dream metadata tracking via onComplete did not fire in ACP mode. That caveat is the real story. Memory commands are not normal slash commands. /remember, /forget, and /dream mutate durable context — the agent's memory of the work, the conversation, the state that persists across sessions. ACP mode is where Qwen Code stops being a local terminal session and becomes a protocol-driven runtime that other clients can operate programmatically. If the lifecycle hooks differ between interactive and ACP paths, "same command, different mode" is not actually same behavior. It is how observability gaps, retention bugs, and surprise state mutations enter agent products. The onComplete caveat meant memory writes in ACP mode were not being tracked — which means they were not being audited, not being deduplicated, and not being cleaned up through the normal path.

This is the kind of rollback that deserves attention precisely because it is not framed as a failure. The Qwen Code team did not ship a blog post about it. They did not announce it on Twitter. They reverted it cleanly and moved on. But for anyone building with Qwen Code's ACP surface — and the number of teams doing that is growing — this is an important signal: protocol-mode parity with interactive mode is not guaranteed just because the same command name exists in both surfaces. Stateful commands need stateful equivalence tests. The fact that the team caught and reverted this within roughly 24 hours suggests their internal testing caught the onComplete discrepancy before it propagated into user-facing memory records.

The surrounding work in the June 8 release makes the rollback more interesting, not less. The release still bundles installer asset verification from PR #3855 — 110 review comments across 30 commits, hardening the distribution pipeline itself rather than just adding features. It includes standalone auto-update support from PR #4629 — 78 review comments across 24 commits, separating "update in background while runtime is live" from "update that requires explicit restart." It carries forward subagent telemetry from PR #4410 — 105 review comments across 17 commits, adding qwen-code.subagent spans with concurrent isolation. And PR #4432 adds retry visibility for qwen-code.llm_request — 28 review comments across 3 commits. The automated @qwen /triage workflow PR #4768 adds issue and PR triage that runs inside the project's own governance loop.

The skills-picker work from PR #4533 adds browsing, searching, toggling, and hiding skills from both model-visible <available_skills> and slash-command surfaces. This is capability exposure as an access-control surface, not just a UX improvement. Once skills are exposed to the model and the user can toggle them, you have a permission boundary that needs to be enforced, audited, and governable — especially in ACP mode where external clients can invoke capabilities programmatically.

Put together, Qwen Code is converging on the same runtime concerns as hosted coding agents, but with a local and BYOK posture and a faster nightly cadence. That is attractive for teams that want control, and risky for teams that mistake "open source and local" for "automatically governed." The Qwen OAuth free tier discontinuation notice in the auth docs — discontinued April 15, 2026 — is a reminder that "local" still has external dependencies. The plaintext fallback warning for credentials stored in settings.json is another.

The actionable takeaway is not "Qwen Code has a memory bug." The takeaway is: test protocol modes as separate products. If you enable Qwen Code in ACP mode, write regression tests for memory writes, deletes, skill enable/disable behavior, prompt expansion hooks, subagent tracing, retry logs, and auto-update constraints. Decide who can mutate memory through ACP, where those records live, how they are deleted, and whether telemetry proves the deletion happened. The rollback is not a black mark. It is a useful reminder that agent memory is infrastructure. Treat it like one.

The broader pattern here is worth sitting with. The coding-agent space is developing a genuinely mature engineering culture around release discipline, rollback readiness, and protocol-mode parity testing. Qwen Code reverted a feature within 24 hours of shipping it. That is not weakness. That is the right behavior from a team that understands its protocol surface is becoming a product surface, and that product surfaces need downgrade paths, auditability, and clear permission boundaries. Local agents are becoming protocol runtimes. Durable memory in ACP and MCP-style surfaces needs governance before parity — and this rollback is evidence that the Qwen team is actually thinking about that, even if the release notes do not say so explicitly.

Sources: Qwen Code v0.17.1-nightly.20260608, PR #4818, PR #4811, PR #4410, PR #4432, PR #4533