QwenPaw v1.1.11 Moves the Local-Agent Stack Toward Marketplaces, OAuth, and MCP Controls

QwenPaw v1.1.11 is not just another local-agent release with a few more integrations stapled on. It is a useful market signal: the personal-agent stack is converging on the same shape everywhere. Local runtime, chat channels, OAuth onboarding, plugin marketplace, MCP controls, multi-agent metadata, approval flows, and a web console. Different mascot, same control-plane gravity.

The release, published on June 10 at 2026-06-10T14:49:54Z, comes from the AgentScope/Qwen side of the ecosystem. At research time the repository had about 17,378 stars, 2,594 forks, and 856 open issues. That is not OpenClaw-scale gravity, but it is large enough to matter — especially because QwenPaw is strongest in the channel geography many Western agent stacks still treat as an edge case: DingTalk, Feishu, QQ, WeChat-adjacent workflows, Yuanbao, and Chinese developer environments.

The headline features in v1.1.11 are broad: Free Model OAuth, Xiaomi MiMo Token Plan provider support, non-standard generate_kwargs routing into extra_body, a Plugin Market tab integrated with AgentScope Platform, plugin extension infrastructure, tool cards, external URL navigation, per-server MCP tool whitelisting, Telegram tool approval via inline keyboard, Feishu group sharing, QQ QR auth, DingTalk inline media cards, Yuanbao typing indicators, unified sender username access control, ACP command metadata, and self-evolving skill creation.

That is a mouthful. The important part is that QwenPaw is moving from “assistant you run locally” toward “agent operating environment.” Once a project has OAuth onboarding, plugins, marketplaces, MCP, chat-channel approvals, and ACP metadata, it is no longer competing only on model quality. It is competing on governance.

MCP whitelisting is the practical line item

The most immediately useful engineering addition is per-server MCP tool whitelisting with a frontend toggle UI. This is exactly the kind of feature operators need before MCP becomes default wiring. A single MCP server can expose a pile of tools: some read-only, some write-capable, some safe in one workspace and dangerous in another. “The agent will choose wisely” is not a permission model. It is a prayer with JSON.

Per-server whitelisting does not solve every MCP risk. The server still needs trustworthy schemas, safe implementations, clear audit logs, and sane authentication. But it moves the control closer to the operator and acknowledges the right principle: tool availability should be scoped intentionally, not inherited wholesale because a server was easy to connect.

This matters more as coding agents converge. Developers are already mixing Claude Code, Codex, OpenClaw, Cursor, Gemini-derived tools, local Qwen flows, and custom MCP servers. The MCP layer is becoming a shared tool bus. Shared tool buses need controls, because one overbroad tool surface can turn a helpful assistant into a very polite incident report.

The marketplace is both the product and the risk

The Plugin Market tab integrated with AgentScope Platform is the second big signal. Agent platforms eventually need distribution. Nobody wants to copy shell snippets from random READMEs forever. A marketplace gives users discovery, installation, updates, ratings, and a path for developers to ship useful extensions.

It also imports the old supply-chain problem in a more dangerous costume. A plugin for a static site generator can break a build. A plugin for a local agent may get access to files, messages, browser context, tokens, and tool calls. Metadata can be prompt-injection material. Install hooks can have side effects. Skill descriptions can persuade a model to route work through a malicious tool. Package provenance and review policy become security infrastructure, not community niceties.

QwenPaw’s release mentions plugin extension infrastructure, tool cards, uninstall hooks, CloudPaw agent import, skill tag batch download, multi-path skill pools, and self-evolving skill creation. Those are all useful product moves. They also expand the attack surface. Self-evolving skills are particularly double-edged: letting an agent write or refine its own capabilities can compound productivity, but it also means the platform must be very clear about who can create skills, where they are stored, how they are reviewed, what tools they can bind, and how an operator rolls them back.

The right question for teams is not “does QwenPaw have a plugin market?” It is “can we audit what was installed, why it was allowed, what authority it received, and how to revoke it?” If the answer is fuzzy, the marketplace is still a demo feature.

OAuth onboarding is not just convenience

The Free Model OAuth addition is worth reading carefully. Qwen Code’s own documentation says the Qwen OAuth free tier for Qwen Code was discontinued on April 15, 2026, so any new “free model OAuth” positioning deserves validation in practice. Free tiers change. OAuth scopes matter. Token storage matters. Revocation matters. The boring implementation details decide whether onboarding is friendly or whether it quietly spreads credentials across machines and channels.

Still, the direction is understandable. Agent stacks that expect users to paste long-lived API keys into local config files are going to feel increasingly primitive. OAuth can reduce copy-paste secret handling and support revocation, device flows, and scoped access. But the platform has to treat OAuth as identity infrastructure, not a marketing badge. Where are refresh tokens stored? Are they encrypted? Can a workspace use a different identity from a personal chat channel? Does the agent know when a token is user-delegated versus service-owned?

The channel work points in the same governance direction. Telegram inline approval for tools makes human-in-the-loop execution less clumsy. QQ QR code auth, Feishu group sharing, DingTalk inline media cards, and unified sender username access control make QwenPaw more usable in the environments where its likely users already collaborate. But each channel is also a policy domain. Group chats, personal DMs, enterprise Feishu spaces, and QQ sessions should not collapse into one ambient instruction stream.

For builders evaluating QwenPaw, the practical checklist is straightforward. Test MCP whitelisting before connecting sharp tools. Inspect plugin install and uninstall behavior before trusting the marketplace. Validate OAuth storage and revocation. Confirm channel identity mapping, especially in group contexts. Try local models and remote providers separately, and make sure memory does not move somewhere surprising. If your deployment is China-heavy or Qwen-native, QwenPaw is absolutely worth watching. But judge it on control-plane maturity, not mascot energy or model branding.

The larger takeaway is that QwenPaw is not “OpenClaw, but Qwen.” It is evidence that personal-agent platforms are standardizing around a marketplace-plus-MCP control plane. That is good news if the security model matures at the same speed as the plugin catalog. If it does not, the category will rediscover browser extension security, npm supply-chain risk, and chat-bot authorization bugs all at once. We have seen that movie. It has too many sequels.

Sources: QwenPaw v1.1.11 release, QwenPaw repository, Qwen Code authentication docs, piwheels QwenPaw project page