QwenLM a publié Qwen Code 0.24.1 le 19 septembre. Cette version introduit une fonction utile aux équipes qui organisent le travail de plusieurs agents : elles peuvent désormais définir, pour chaque sous-agent d'un processus, les outils auxquels il a accès. Les notes de version annoncent aussi une bibliothèque fondée sur Playwright pour interagir avec un navigateur. Ces nouveautés ne sont pourtant pas au même stade. La première est intégrée au système qui répartit les tâches entre agents. La seconde constitue une base technique ; les auteurs précisent expressément que cette première étape ne rend pas encore la navigation accessible depuis l'outil en ligne de commande.
Cette distinction a des conséquences pratiques. Imaginons un processus dans lequel une première étape lit des fichiers, une autre exécute quelques commandes et la dernière rédige un compte rendu. Donner à chaque étape toutes les capacités disponibles augmente inutilement les possibilités d'action en cas d'instruction erronée. À l'inverse, croire qu'une bibliothèque présente dans le dépôt constitue déjà une fonction opérationnelle peut conduire à déployer un processus impossible à exécuter sur les machines de l'entreprise. L'intérêt de cette livraison est précisément de séparer une restriction immédiatement intégrée d'une fonctionnalité en cours d'assemblage, à partir des documents publiés par le projet.
Limiter chaque sous-agent aux opérations nécessaires
Une modification fusionnée dans le dépôt ajoute l'option tools à l'appel agent(). Un script peut ainsi demander que le sous-agent concerné ne dispose que de read_file et run_shell_command. Le programme confronte la liste demandée aux autorisations existantes du type d'agent et retire les outils déjà interdits. Il ne suffit donc pas de citer un nom pour obtenir un droit supplémentaire. La sélection finale est transmise au mécanisme de déclaration d'outils déjà utilisé par l'agent, plutôt que d'être gérée par un nouveau système de permissions parallèle.
Jusqu'ici, l'option disallowedTools imposait surtout une logique d'exclusion : pour limiter une étape à deux outils, il fallait connaître et interdire tous les autres. L'arrivée d'un nouvel outil ou d'un serveur MCP pouvait rendre cette liste incomplète. Désormais, une étape peut déclarer explicitement ce dont elle a besoin. Cette démarche simplifie également les audits : pourquoi ce sous-agent doit-il exécuter une commande, ouvrir un fichier ou utiliser un outil externe ? Il s'agit d'une analyse de la conception annoncée. Aipolix n'a pas mené de campagne indépendante pour mesurer son efficacité face à des agents malveillants.
Le comportement exact mérite attention. Seuls les noms précis des outils sont acceptés. Un motif générique, un serveur MCP désigné dans son ensemble ou l'entrée spéciale exec entraînent un refus. Dans le mode où l'exécution de code sert d'interface aux autres outils, exec reste disponible, mais les outils qu'il peut appeler sont limités. Une erreur de nom peut être rejetée avant le lancement de l'agent. Les auteurs signalent une autre nuance : un nom valide peut correspondre à un outil qui n'est finalement pas visible dans la session ; l'agent dispose alors de moins de fonctions que prévu. Il faut donc contrôler les outils réellement déclarés, et non se contenter de relire la configuration.
Pourquoi la bibliothèque de navigation ne suffit pas
L'autre nouveauté est une interface typée destinée à fonctionner dans un environnement Node REPL persistant avec une session Chrome existante. Elle repose sur Playwright et unifie trois façons de repérer les éléments : les sélecteurs sémantiques, les références à la structure du document et les coordonnées à l'écran. Elle prévoit la gestion des onglets, la navigation, la saisie, les captures, les boîtes de dialogue et la synchronisation des téléchargements. Ces possibilités décrivent le socle logiciel, pas nécessairement les commandes utilisables dès maintenant par le public.
Le plan de développement comporte trois étapes. La première crée la bibliothèque et ses contrats de communication. La deuxième établit le lien avec Chrome à l'aide d'un programme de communication local et d'une extension. La troisième intègre l'ensemble à Qwen Code. Le texte de la première demande de modification est sans ambiguïté : à elle seule, elle n'active pas Browser Use dans l'application en ligne de commande et ne modifie pas les permissions de l'extension. Il mentionne également des limites, notamment une seule session par utilisateur du système, l'absence de prise en charge de Windows dans cette première étape et certains essais sous Linux qui restent à reprendre. Ce sont les limites décrites par les auteurs, et non les résultats d'essais effectués par Aipolix.
Vérifier les deux fonctions séparément
Notre recommandation méthodologique consiste à procéder à deux essais distincts. Pour la liste d'outils, créer un petit processus avec des permissions restreintes, puis examiner les déclarations réellement reçues par le sous-agent. Il faut essayer d'appeler un outil exclu, répéter l'essai en mode d'exécution de code si nécessaire et contrôler soigneusement les noms et la disponibilité des outils MCP. Le simple fait qu'un fichier de configuration présente une liste correcte ne prouve pas que la session finale contient exactement les capacités attendues.
Pour le navigateur, vérifier la distribution réellement installée : la liaison avec Chrome et l'intégration à l'application sont-elles toutes deux disponibles, ou seul le socle logiciel est-il présent ? La mention d'une bibliothèque dans les notes de version ne suffit pas à répondre. La livraison comporte aussi un changement incompatible : l'événement de flux signalant l'objectif actif cesse d'être émis. Les logiciels qui dépendent précisément de cet événement doivent vérifier leur compatibilité avant la mise à jour ; il ne s'agit pas d'une suppression générale de tous les événements.
Qwen Code 0.24.1 apporte ainsi un moyen concret de restreindre les outils de chaque étape, tout en préparant une future intégration du navigateur. Une liste d'autorisations n'est pas une protection universelle, et une bibliothèque n'est pas un produit complet. Pour adopter la version sans confondre ces notions, les équipes ont intérêt à vérifier les capacités effectivement proposées dans leur installation et à éprouver les restrictions dans leurs propres processus.