Commandes

Ce document détaille toutes les commandes prises en charge par Qwen Code, vous aidant à gérer efficacement les sessions, à personnaliser l’interface et à contrôler son comportement.

Les commandes de Qwen Code sont déclenchées via des préfixes spécifiques et se répartissent en trois catégories :

1. Commandes slash (/)

Les commandes slash sont utilisées pour gérer les sessions, l’interface et le comportement de base de Qwen Code.

1.1 Gestion des sessions et des projets

Ces commandes vous aident à sauvegarder, restaurer et résumer l’avancement du travail.

1.2 Contrôle de l’interface et de l’espace de travail

Commandes pour ajuster l’apparence de l’interface et l’environnement de travail.

1.3 Paramètres de langue

Commandes spécifiquement dédiées au contrôle de la langue de l’interface et de la sortie.

• Langues de l’interface intégrées disponibles : zh-CN (chinois simplifié), en-US (anglais), ru-RU (russe), de-DE (allemand), ja-JP (japonais), pt-BR (portugais - Brésil), fr-FR (français), ca-ES (catalan)
• Exemples de langues de sortie : Chinese, English, Japanese, etc.

1.4 Gestion des outils et des modèles

Commandes pour gérer les outils et les modèles d’IA.

1.5 Skills intégrées

Ces commandes invoquent des skills intégrées qui fournissent des workflows spécialisés.

Consultez Code Review pour la documentation complète de /review.

1.6 Question annexe (/btw)

La commande /btw vous permet de poser des questions annexes rapides sans interrompre ni affecter le flux de la conversation principale.

Fonctionnement :

• La question annexe est envoyée via un appel API séparé avec le contexte de conversation récent (jusqu’aux 20 derniers messages)
• La réponse s’affiche au-dessus du Composer — vous pouvez continuer à taper en attendant
• La conversation principale n’est pas bloquée — elle continue indépendamment
• La réponse à la question annexe ne fait pas partie de l’historique de la conversation principale
• Les réponses sont rendues avec le support complet du Markdown (blocs de code, listes, tableaux, etc.)

Raccourcis clavier (Mode interactif) :

Exemple :

(While the main conversation is about refactoring code)

> /btw What's the difference between let and var in JavaScript?

  ╭──────────────────────────────────────────╮
  │ /btw What's the difference between let   │
  │     and var in JavaScript?               │
  │                                          │
  │ + Answering...                           │
  │ Press Escape, Ctrl+C, or Ctrl+D to cancel│
  ╰──────────────────────────────────────────╯
  > (Composer remains active — keep typing)

(After the answer arrives)

  ╭──────────────────────────────────────────╮
  │ /btw What's the difference between let   │
  │     and var in JavaScript?               │
  │                                          │
  │ `let` is block-scoped, while `var` is    │
  │ function-scoped. `let` was introduced    │
  │ in ES6 and doesn't hoist the same way.   │
  │                                          │
  │ Press Space, Enter, or Escape to dismiss │
  ╰──────────────────────────────────────────╯
  > (Composer still active)

Modes d’exécution supportés :

1.7 Second avis (/advisor)

La commande /advisor exécute une revue indépendante et en lecture seule de la conversation jusqu’à ce point et renvoie un second avis structuré — sans effectuer la tâche ni interrompre la conversation principale.

Fonctionnement :

• La revue est envoyée via un appel API séparé et en tour unique avec le contexte de conversation récent (jusqu’aux 40 derniers messages)
• Le modèle relecteur ne peut pas exécuter d’outils — les outils sont retirés au niveau de la requête (le même mécanisme que /btw), donc la revue n’écrit jamais de code ni n’exécute de commandes ; chaque affirmation doit être ancrée dans la transcription visible
• La conversation principale n’est pas interrompue ; la revue vous est montrée uniquement
• La revue est rendue sous forme de bloc markdown encadré avec quatre sections fixes — Verdict, Risques, Preuves manquantes et Recommandation — sous un en-tête /advisor · <model> qui nomme le modèle relecteur résolu
• Contrairement à /btw, qui est fire-and-forget et laisse la session utilisable, /advisor bloque la saisie jusqu’au retour de la revue ; sur une fenêtre de contexte complète avec un relecteur puissant, cela peut prendre des dizaines de secondes
• Par défaut, le modèle principal est utilisé ; définissez advisorModel pour acheminer la revue vers un modèle différent (généralement plus puissant) — la transcription récente est envoyée à ce modèle même s’il utilise un autre fournisseur

Exemple :

> /advisor is my fix for the null check actually correct?

  Consulting advisor...

  ╭──────────────────────────────────────────────────────╮
  │ /advisor · qwen3-max                                 │
  │                                                      │
  │ Verdict                                              │
  │ The approach is sound, but the edge case at line 42  │
  │ is unverified.                                       │
  │                                                      │
  │ Risks                                                │
  │  - The fix assumes the config is always loaded; a    │
  │    startup race could leave it null.                 │
  │                                                      │
  │ Missing evidence                                     │
  │  - No test exercises the null-config path in the     │
  │    visible transcript.                               │
  │                                                      │
  │ Recommendation                                       │
  │ Add a focused unit test for the null-config branch   │
  │ before merging.                                      │
  ╰──────────────────────────────────────────────────────╯

La revue s’affiche dans une boîte encadrée dont l’en-tête nomme le modèle relecteur résolu. Un advisorModel inconnu n’est pas validé au préalable — si le fournisseur le rejette, /advisor signale l’échec, vérifiez donc le nom du modèle ; seuls les sélecteurs d’alias non résolus (par ex. fast sans modèle rapide configuré) reviennent au modèle principal. Les requêtes Advisor n’utilisent pas les fallbacks de modèle configurés.

Modes d’exécution supportés :

1.8 Récapitulatif de session (/recap)

La commande /recap génère un court résumé “où vous en étiez” de la session en cours, afin que vous puissiez reprendre une ancienne conversation sans avoir à faire défiler des pages d’historique.

Fonctionnement :

• Utilise le modèle rapide configuré (paramètre fastModel) lorsqu’il est disponible, sinon revient au modèle de session principal. Un modèle petit et peu coûteux suffit pour un récapitulatif.
• La conversation récente (jusqu’à 30 messages, texte uniquement — les appels d’outils et les réponses d’outils sont filtrés) est envoyée au modèle avec un system prompt strict.
• Le récapitulatif est rendu en couleur atténuée avec un préfixe ❯ pour le distinguer des vraies réponses de l’assistant.
• Refuse avec une erreur inline si un tour de modèle est en cours ou si une autre commande est en cours de traitement. S’il n’y a pas de conversation utilisable, ou si la génération sous-jacente échoue, /recap affiche un court message d’information au lieu d’un récapitulatif — la commande manuelle répond toujours avec quelque chose.

Déclenchement automatique au retour après une absence :

Si le terminal perd le focus pendant 5 minutes ou plus et le récupère, un récapitulatif est généré et affiché automatiquement (uniquement lorsqu’aucune réponse de modèle n’est en cours ; sinon, il attend la fin du tour en cours puis se déclenche). Contrairement à la commande manuelle, le déclenchement automatique est totalement silencieux en cas d’échec : si la génération échoue ou s’il n’y a rien à résumer, aucun message n’est ajouté à l’historique. Contrôlé par le paramètre general.showSessionRecap (par défaut : false) ; la commande manuelle /recap fonctionne toujours indépendamment de ce paramètre.

Exemple :

> /recap

❯ Refactoring loopDetectionService.ts to address long-session OOM caused by
  unbounded streamContentHistory and contentStats. The next step is to
  implement option B (LRU sliding window with FNV-1a) pending confirmation.

1.9 Visionneuse de diff (/diff)

La commande /diff ouvre une visionneuse de diff interactive affichant les modifications non commitées et les diffs par tour. Utilisez ←/→ pour basculer entre le git diff actuel et les tours de conversation individuels, ↑/↓ pour parcourir les fichiers, et Enter pour voir les diffs inline.

Fonctionnement :

En mode interactif, /diff ouvre une boîte de dialogue avec un sélecteur de source en haut :

• Current — working tree vs HEAD (git diff HEAD). Affiche toutes les modifications non commitées, y compris les fichiers stagés, non stagés et non suivis.
• T1, T2, T3, … — diffs par tour, un onglet par tour de modèle qui a modifié des fichiers. Les tours les plus récents apparaissent en premier. Chaque onglet affiche un aperçu du prompt original pour le contexte.

La liste de fichiers affiche les statistiques par fichier (lignes ajoutées/supprimées) avec des tags pour les états spéciaux (new, deleted, untracked, binary, truncated, oversized). Appuyez sur Enter sur un fichier pour voir son diff inline avec les hunks colorés syntaxiquement.

Les diffs par tour nécessitent que le checkpointing de fichiers soit activé (activé par défaut en mode interactif). Lorsque le checkpointing de fichiers est désactivé, seule la source “Current” est disponible.

Raccourcis clavier :

Exemple :

┌ /diff · Turn 3 "refactor the auth middleware" ──── 3 files +45 -12 ┐
│                                                                     │
│ ◀ Current · T3 · T2 · T1 ▶                                         │
│                                                                     │
│ › src/utils/parser.ts                              +30 -8           │
│   src/utils/parser.test.ts                         +12 -2           │
│   README.md                                        +3 -2            │
│                                                                     │
│ ←/→ source · ↑/↓ file · Enter view · Esc close                     │
└─────────────────────────────────────────────────────────────────────┘

Mode non interactif :

En mode headless (--prompt) ou dans des contextes non interactifs, /diff affiche un résumé en texte brut du working tree vs HEAD. La navigation par tour n’est pas disponible.

3 files changed, +45 / -12
  +30  -8  src/utils/parser.ts
  +12  -2  src/utils/parser.test.ts
   +3  -2  README.md

Web Shell : Dans l’interface Web Shell (qwen serve), /diff ouvre une boîte de dialogue graphique de diff. Une barre d’onglets en haut vous permet de basculer entre la vue Changes et la vue History (/log).

Visualiseur d’historique (/log) — Web Shell uniquement

La commande /log ouvre un navigateur d’historique de commits pour le workspace actuel. Elle est disponible uniquement dans l’interface Web Shell ; le CLI/TUI ne dispose pas de cette commande.

Fonctionnement :

/log ouvre une boîte de dialogue listant les commits par ordre chronologique inverse (les plus récents en premier). Chaque ligne affiche :

• SHA court (monospace, avec un bouton de copie pour le SHA complet)
• Sujet du commit (une seule ligne)
• Nom de l’auteur et temps relatif (par ex. “2h ago”)
• Étiquettes de référence branche/tag, lorsque présentes
• Une icône de merge (⎇) pour les commits de merge

Cliquez sur une ligne de commit pour déplier ses détails à la demande :

• Corps complet du message de commit
• Statistiques de modification des fichiers (fichiers modifiés, lignes ajoutées/supprimées, détail par fichier)

Utilisez Load more en bas pour récupérer la page suivante de commits (50 par page).

Exemple :

┌─ History ──────────────────────────── 50 commits ─ ✕ ┐
│                                                       │
│  a1b2c3d  feat(cli): add --json flag        2h ago   │
│           wenshao                                    │
│                                                       │
│  e4f5g6h  fix(core): handle null config     5h ago   │
│           dev · main  v1.2.0                         │
│                                                       │
│ ▼ 789abcd  refactor: simplify parser        1d ago   │
│   ┌─────────────────────────────────────────────┐    │
│   │  Broke the monolithic parse() into smaller  │    │
│   │  functions for readability.                 │    │
│   │                                             │    │
│   │  3 files · +45 −12                          │    │
│   │   +30 −8   src/parser.ts                    │    │
│   │   +10 −2   src/utils.ts                     │    │
│   │   +5  −2   test/parser.test.ts              │    │
│   └─────────────────────────────────────────────┘    │
│                                                       │
│              [ Load more ]                            │
└───────────────────────────────────────────────────────┘

1.10 Informations, paramètres et aide

Commandes pour obtenir des informations et configurer le système.

1.11 Raccourcis courants

1.12 Commandes d’authentification

Utilisez /auth dans une session Qwen Code pour configurer l’authentification. Utilisez /doctor pour inspecter l’état actuel de l’authentification et de l’environnement.

2. Commandes @ (Introduction de fichiers)

Les commandes @ sont utilisées pour ajouter rapidement le contenu d’un fichier ou d’un répertoire local à la conversation.

Note : Les espaces dans les chemins doivent être échappés avec un antislash (par ex. @My\ Documents/file.txt)

3. Commandes avec point d’exclamation (!) - Exécution de commandes Shell

Les commandes avec point d’exclamation vous permettent d’exécuter des commandes système directement dans Qwen Code.

Variables d’environnement : Les commandes exécutées via ! définiront la variable d’environnement QWEN_CODE=1.

4. Commandes personnalisées

Enregistrez les prompts fréquemment utilisés comme commandes raccourcies pour améliorer l’efficacité du travail et garantir la cohérence.

Aperçu rapide

Règles de priorité : Commandes de projet > Commandes utilisateur (la commande de projet est utilisée en cas de noms identiques)

Règles de nommage des commandes

Tableau de correspondance entre le chemin du fichier et le nom de la commande

Règles de nommage : Le séparateur de chemin (/ ou \) est converti en deux-points (:)

Spécification du format de fichier Markdown (Recommandé)

Les commandes personnalisées utilisent des fichiers Markdown avec un frontmatter YAML optionnel :

---
description: Description optionnelle (affichée dans /help)
---
 
Votre contenu de prompt ici.
Utilisez {{args}} pour l'injection de paramètres.

Format de fichier TOML (Obsolète)

Mécanisme de traitement des paramètres

1. Injection contextuelle ({{args}})

2. Traitement des paramètres par défaut

🚀 Injection de contenu dynamique

3. Exécution de commandes Shell (!{...})

Exemple : Génération de message de commit Git

---
description: Générer un message de commit basé sur les modifications indexées
---
 
Veuillez générer un message de commit basé sur le diff suivant :
 
```diff
!{git diff --staged}
```

4. Injection de contenu de fichier (@{...})

Exemple : Commande de revue de code

---
description: Revue de code basée sur les bonnes pratiques
---
 
Réviser {{args}}, standards de référence :
 
@{docs/code-standards.md}

Exemple de création pratique

Tableau des étapes de création de la commande “Refactoring en fonction pure”

---
description: Refactorer le code en fonction pure
---
 
Veuillez analyser le code dans le contexte actuel, refactorer en fonction pure.
Exigences :
 
1. Fournir le code refactorisé
2. Expliquer les changements clés et l'implémentation des caractéristiques des fonctions pures
3. Maintenir la fonction inchangée

Résumé des bonnes pratiques pour les commandes personnalisées

Tableau des recommandations pour la conception des commandes

Tableau récapitulatif des fonctionnalités de sécurité

5. Sous-commandes CLI

Ces commandes sont exécutées depuis le shell sous la forme qwen <subcommand> avant de démarrer une session interactive.

Gestion des sessions

qwen sessions list

Liste vos sessions Qwen Code récentes avec leurs métadonnées.

Options :

Sortie lisible par l’homme (par défaut) :

Un tableau avec les colonnes : SESSION ID, STARTED (horodatage UTC), TITLE, BRANCH, PROMPT.

Sortie JSON (--json) :

Génère des JSON Lines sur stdout. Chaque ligne est un objet JSON contenant les champs suivants :

sessionId, startTime, mtime, prompt, gitBranch, customTitle, titleSource, filePath, cwd

L’indication « has more sessions » est émise via stderr afin que le piping vers jq reste sûr.

Exemples :

# Affiche les 20 dernières sessions (par défaut)
qwen sessions list
 
# Affiche les 50 dernières sessions
qwen sessions list --limit 50
 
# Sortie au format JSON pour les scripts
qwen sessions list --json | jq .

qwen sessions ps

Liste les sessions interactives Qwen Code en cours d’exécution sur cette machine. sessions list parcourt les transcriptions sauvegardées (« sur quoi ai-je travaillé ») ; celui-ci parcourt le registre des processus actifs (« qu’est-ce qui tourne en ce moment »). Les enregistrements laissés par une session tuée sont balayés au fur et à mesure. Les sessions headless (qwen -p) ne s’enregistrent pas dans le registre des processus actifs, elles ne sont donc pas affichées.

Options :

Sortie lisible par l’homme (par défaut) :

Un tableau avec les colonnes : NAME, KIND, PID, AGE, DIRECTORY.

KIND indique ce qui a enregistré la session — tui pour quelqu’un devant un terminal, external pour un programme qui n’est pas du tout une session Qwen Code (un front-end vocal, un relay), et headless ou serve pour une session pilotée par un autre programme. Plusieurs lignes serve ou headless peuvent partager un même PID : un enfant qwen --acp héberge toutes ses sessions dans un seul processus — serve quand le démon l’a engendré, headless quand un client le pilote directement — et chacune s’enregistre séparément. C’est un auto-rapport, comme NAME et DIRECTORY : chaque champ ici a été écrit par le processus qu’il décrit, et rien de ce qu’une session est autorisée à faire n’en dépend. Voir Cross-Session Protocol pour le format d’enregistrement et comment enregistrer votre propre programme.

Sortie JSON (--json) :

Génère des JSON Lines sur stdout, la session la plus récente en premier. Chaque ligne est un objet JSON contenant les champs suivants :

schemaVersion, pid, procStart, pidNs, sessionId, cwd, name, startedAt,
qwenVersion, kind, ipcPath (lorsque la messagerie entre pairs est disponible)

Rien d’autre n’est écrit sur stdout — un listing vide n’imprime rien du tout — donc qwen sessions ps --json | jq . est sûr pour les scripts.

La sortie JSON est des données brutes : les valeurs des champs sont émises exactement telles qu’enregistrées, sans assainissement de terminal. Traitez-les comme des données, et assainissez-les avant de les afficher dans un terminal.

Exemples :

# Afficher les autres sessions live
qwen sessions ps
 
# Quels répertoires sont occupés en ce moment ?
# Note : `jq -r` affiche la valeur brute enregistrée dans votre terminal (voir
# la note sur les données brutes ci-dessus) ; faites passer par un assainisseur si le chemin n'est pas fiable.
qwen sessions ps --json | jq -r .cwd

6. Envoyer des messages à une autre session en cours

Deux sessions interactives sur la même machine peuvent s’envoyer des messages. Cette fonctionnalité est expérimentale et désactivée par défaut ; activez-la dans settings.json et redémarrez :

{ "agents": { "crossSessionMessaging": true } }

Une fois activée, le modèle d’une session peut découvrir les autres avec list_agents — chacune apparaît sous sessions avec le name que qwen sessions ps --json enregistre (la vue tableau peut tronquer les noms longs) — et en adresser une avec send_message en utilisant ce nom comme to. Lorsque deux sessions partagent le même nom, list_agents affiche chacune avec un court [ref] et l’envoi doit l’inclure (name [ref]) ; un nom nu qui pourrait correspondre à l’une ou l’autre est refusé plutôt que deviné. list_agents rapporte également le nom de la session elle-même sous self, et to: "*" signifie toujours « mes coéquipiers Agent Team » et n’atteint jamais d’autres sessions.

Un message arrive dans l’autre session marqué comme provenant d’une autre session, pas de son utilisateur, et ne porte aucune de votre autorité : la session réceptrice n’agit dessus que dans le cadre de ses propres paramètres de permissions. Son utilisateur peut choisir ce qui arrive aux messages entrants avec agents.crossSessionInbound (accept, hold ou refuse). Lorsque ce n’est pas défini, un message n’est délivré que lorsque les deux sessions sont dans la même classe de review : les deux reviewent chaque action (mode default ou plan), ou les deux sont dans un mode qui applique certaines actions sans review par action (auto-edit, auto ou yolo). Un message provenant d’une session de l’autre classe, ou d’un expéditeur qui n’indique pas dans quelle classe il se trouve, est mis en attente pour review — dans les deux directions. Une session qui review chaque action met en attente un message provenant d’une session qui ne le fait pas, car ce message a été écrit par un modèle que personne ne surveillait, et les prompts par action protègent les actions, pas ce qu’on dit à la session. Les messages en attente sont listés et libérés avec /peers dans la session réceptrice, et un message mis en attente uniquement parce que les modes différaient est libéré de lui-même une fois qu’ils s’accordent.

Un dépôt peut rendre les sessions qui y sont ouvertes plus prudentes, jamais moins : un .qwen/settings.json de workspace peut définir agents.crossSessionInbound à hold ou refuse, ou agents.crossSessionMessaging à false, et cette valeur l’emporte sur une valeur plus permissive dans vos paramètres utilisateur. Une valeur de workspace qui assouplirait votre paramètre (accept, ou true pour le switch) est ignorée avec un avertissement, et une valeur que le CLI ne reconnaît pas met en attente chaque message lorsqu’elle est la valeur effective. Les paramètres système l’emportent sur tout cela, comme pour chaque paramètre.

Une mise en attente n’attend pas indéfiniment. Un message sur lequel personne ne se décide expire après agents.crossSessionHeldExpiry — 1m, 5m, 10m ou never, cinq minutes par défaut — et la session expéditrice est informée qu’aucune décision n’a été prise. Raccourcir le paramètre s’applique aux messages déjà en attente.

Si la session ne peut pas binder sa boîte de réception — le répertoire runtime est manquant, appartient à un autre utilisateur, ou est en lecture seule, comme cela peut être le cas dans un conteneur — elle essaie d’abord un répertoire privé sous le répertoire temporaire, et seulement si cela échoue aussi, elle démarre sans boîte de réception. Lorsque cela se produit, la session le signale au démarrage, et /peers répète la raison et quoi modifier (généralement XDG_RUNTIME_DIR ou TMPDIR).

Deux sessions peuvent aussi résoudre la même adresse de boîte de réception, car l’adresse est indexée par l’id de processus et les ids de processus se répètent à travers les conteneurs qui partagent un répertoire runtime. La session qui démarre en deuxième prend une adresse voisine au lieu de prendre celle en cours d’utilisation, ainsi aucune ne devient injoignable. Les pairs ne sont pas affectés : ils lisent l’adresse d’une session depuis le registre de sessions plutôt que de la dériver.

L’appel send_message confirme uniquement que le message a été remis à l’autre session. Ce qu’il est advenu arrive plus tard sous forme de reçu : s’il a été mis en attente, décliné, refusé, abandonné, a expiré, ou était mal adressé (l’adresse a changé de titulaire — listez à nouveau les agents) — ou libéré après une mise en attente — une notification apparaît dans la transcription de la session expéditrice (Message to <name>: …). Décliné, refusé et abandonné sont trois réponses différentes : décliné signifie que quelqu’un a examiné le message et a dit non, refusé signifie que le agents.crossSessionInbound de cette session est refuse et personne ne l’a vu du tout, et abandonné signifie que sa boîte de réception a rejeté le message avant tout cela (voir ci-dessous). Le premier abandon est répondu immédiatement et les autres sont regroupés dans un reçu toutes les quelques secondes, chacun nommant les messages qu’il représente, donc une série d’entre eux ne coûte que quelques lignes plutôt qu’une ligne chacun. Le modèle qui l’a envoyé n’en est pas informé ; si l’autre session répond, la réponse arrive comme un message inter-sessions.

Protection contre les inondations

Une session accepte jusqu’à 30 messages d’un seul expéditeur d’un coup puis un toutes les deux secondes, et jusqu’à 32 d’un coup de tous les expéditeurs réunis puis un par seconde. La seconde limite existe car un expéditeur se nomme lui-même : faire tourner ce nom obtient un nouveau quota de la première limite mais pas de la seconde. Elle est à peine au-dessus de la première car chaque message accepté génère un reçu, et une session ne peut en envoyer qu’un certain nombre à la fois. Un message provenant d’une autre session qui répète le message précédent de cet expéditeur mot pour mot dans les 30 secondes est également rejeté — un modèle qui boucle sur une phrase génère un nouvel id de message à chaque fois, c’est donc le texte qui le détecte. Les messages provenant d’un script démarré par la session et d’un contrôleur fiable sont exemptés de la vérification de répétition, car un hook qui rapporte la même ligne deux fois rapporte deux faits et une personne qui dit « continue » deux fois le signifie deux fois ; les deux sont toujours soumis aux limites de débit. Enfin, un message qui est accepté mais ne peut pas être mis en file d’attente car la session en a déjà 50 en attente est également rejeté.

Un message rejeté de cette façon n’est jamais mis en attente, jamais montré au modèle, et ne laisse aucune trace, donc l’expéditeur peut réessayer plus tard et arriver à destination. La session réceptrice l’indique dans sa transcription au plus une fois par minute par expéditeur, avec un compteur de ce que cette ligne représente. La session expéditrice reçoit un seul reçu nommant chaque message que la rafale lui a coûté, et sa transcription dit de regrouper ce qui compte encore dans un message ultérieur plutôt que de renvoyer.

Le côté expéditeur n’attend pas pour le savoir. Chaque session suit ce qu’elle a envoyé à chaque adresse et refuse un envoi que le récepteur rejetterait, donc le modèle est informé de regrouper avant que le message ne soit écrit plutôt qu’après — et le récepteur ne dépense jamais de connexion sur un message qu’il allait rejeter.

Authentification de la boîte de réception et injection scriptée

La boîte de réception de chaque session nécessite un token par session : une connexion doit le présenter sur sa première ligne avant qu’un message ne soit lu, et les sessions échangent les tokens automatiquement via les mêmes enregistrements du registre par lesquels elles se découvrent. Les sessions d’une build sans support des tokens peuvent recevoir d’une plus récente, mais leurs envois vers celle-ci sont abandonnés.

Une session exporte sa propre adresse de boîte de réception et un token aux processus enfants comme QWEN_CODE_MESSAGING_SOCKET et QWEN_CODE_MESSAGING_TOKEN, afin qu’un script ou un hook exécuté par la session puisse lui renvoyer un message. C’est un deuxième token enfant qui n’est jamais publié nulle part : seuls les processus que la session a démarrés peuvent le détenir, donc un message qui arrive avec celui-ci est reconnu comme provenant de la session elle-même plutôt que d’une autre session.

{ printf '%s\n' \
    '{"msgV":1,"type":"auth","token":"'"$QWEN_CODE_MESSAGING_TOKEN"'"}' \
    '{"msgV":1,"msgId":"'"$(uuidgen)"'","type":"user","priority":"next","message":{"role":"user","content":"build finished"}}'; \
} | socat - UNIX-CONNECT:"$QWEN_CODE_MESSAGING_SOCKET"

Donnez à chaque injection un msgId frais. La passerelle réceptrice se souvient des ids qu’elle a déjà traités, donc un hook qui en réutilise un est délivré la première fois et silencieusement dédupliqué à chaque exécution suivante. Répéter le même texte est acceptable — la vérification de répétition ci-dessus ne s’applique pas aux propres processus d’une session — mais les limites de débit s’appliquent, donc un hook dans une boucle est rejeté comme n’importe quelle autre inondation.

Un message injecté passe toujours par la passerelle entrante et est marqué comme ne provenant pas de l’utilisateur, mais la passerelle sait qu’il provient du propre processus de la session : selon la parité de mode par défaut, il est délivré sans review (un pair dans la même position serait mis en attente), tandis qu’un agents.crossSessionInbound explicite de hold ou refuse s’applique à lui comme à n’importe quoi d’autre. Le modèle le voit comme <cross_session_message from="own process" origin="own-process"> avec une notification indiquant qu’il provient d’un script ou d’un hook exécuté par la session, pas de l’utilisateur.

Contrôleurs fiables

La règle ci-dessus met en attente un message de tout expéditeur qui n’indique pas dans quelle classe de review il se trouve, et un programme qui n’est pas une session Qwen Code n’en a pas à indiquer. C’est le bon comportement par défaut pour un inconnu, mais pas pour un programme que vous avez choisi : un front-end vocal, un bridge de dictée, un démon d’automatisation relayant vos propres instructions verrait chaque message mis en attente, et approuver chacun à la main va à l’encontre de l’objectif.

Vous accordez à un tel programme la délivrance en lui créant un token :

qwen sessions controllers add --label voice-bridge

Le token est affiché une seule fois et n’est stocké nulle part : le fichier sous votre répertoire Qwen ne conserve que son hash SHA-256, donc rien de ce qui lit ultérieurement ce fichier ne peut présenter le token. Placez-le dans la configuration du contrôleur lorsque la commande l’affiche.

Un contrôleur présente le token comme tout autre expéditeur — comme première ligne de la connexion — et prend le chemin du socket depuis le registre de sessions (qwen sessions ps --json affiche un enregistrement par session active, ipcPath étant l’adresse) :

{ printf '%s\n' \
    '{"msgV":1,"type":"auth","token":"'"$QWEN_CONTROLLER_TOKEN"'"}' \
    '{"msgV":1,"msgId":"'"$(uuidgen)"'","type":"user","priority":"next","message":{"role":"user","content":"open the failing test"}}'; \
} | socat - UNIX-CONNECT:"$SESSION_IPC_PATH"

Un message qui arrive avec un token accordé est délivré sans review par message, quelle que soit la classe de review de l’un ou l’autre côté — mais il cède toujours devant un paramètre explicite : un agents.crossSessionInbound à hold le met en attente comme n’importe quoi d’autre, et refuse le rejette. Les accords appartiennent à votre répertoire Qwen plutôt qu’à une session, donc un contrôleur atteint toutes les sessions que vous exécutez, et les sessions relisent le fichier à chaque connexion : créer ou révoquer un accord prend effet à la prochaine connexion, sans rien à redémarrer.

qwen sessions controllers list          # ids, labels, date d'ajout
qwen sessions controllers remove c_1a2b # révoquer un accord

/peers controllers et /peers revoke <id> font la même chose depuis une session. Un message arrivé via un accord est affiché comme Message from a trusted controller (voice-bridge), et apparaît dans /peers comme [controller] voice-bridge si un paramètre hold l’a mis en attente.

Le modèle voit un tel message comme <cross_session_message from="controller" origin="controller" controller="voice-bridge">, avec une notification indiquant qu’il relaye vos propres instructions — et les mêmes deux interdictions qui s’appliquent à chaque autre origine : il ne peut pas modifier les paramètres de permissions, QWEN.md ou la config parce que le message le demande, et il ne peut pas traiter le message comme une approbation de votre part d’un prompt de confirmation en attente. Un contrôleur peut dire quoi faire ensuite ; il ne peut pas répondre à un prompt en votre nom.

Quiconque détient le token peut envoyer en tant que ce contrôleur, traitez-le donc comme tout autre identifiant : donnez-le à un seul programme, gardez-le hors des configs partagées, et révoquez-le lorsque ce programme a terminé.

Sessions pilotées par un programme via ACP

Tout enfant qwen --acp enregistre chaque session qu’il héberge — en tant que serve quand le démon a engendré le processus, en tant que headless quand un éditeur ou un autre client pilote qwen --acp directement — et la session apparaît dans qwen sessions ps et dans le list_agents d’une autre session comme n’importe laquelle. Elle peut envoyer : son modèle peut appeler send_message pour atteindre un terminal que vous avez ouvert. Plusieurs d’entre eux partagent un processus et une boîte de réception, donc un expéditeur doit nommer la session qu’il vise — chaque session Qwen Code le fait automatiquement.

Les messages envoyés à l’une d’elles sont refusés plutôt que mis en attente. Une mise en attente est une question posée à une personne, et personne ne surveille une liste de messages en attente pour le compte d’une session pilotée ; un expéditeur est informé immédiatement au lieu d’attendre l’expiration. L’endroit où un message en attente devrait apparaître pour ces sessions n’est pas encore fixé.

Une session ne s’enregistre que tant que son propre paramètre agents.crossSessionMessaging est actif. Sans cela, elle reste invisible, car la seule raison de lister une session à laquelle personne ne peut envoyer des messages serait d’annoncer une adresse qui ne répond jamais.

Programmes qui ne sont pas des sessions Qwen Code

Tout ce qui précède fonctionne entre sessions, mais rien n’y est spécifique à une seule. Un programme qui écrit un enregistrement de registre pour lui-même et lie une boîte de réception de la même manière est listé par qwen sessions ps et par list_agents, peut être adressé par nom depuis send_message, et reçoit des accusés de réception pour ce qu’il envoie — un front-end vocal, un relay, un surveillant de build. Il doit enregistrer kind: "external" pour qu’un listing puisse dire ce qu’il est.

Cross-Session Protocol est le contrat pour en écrire un : le schéma d’enregistrement et comment la vitalité est jugée, les chemins de socket et le framing, la ligne d’authentification, chaque champ de trame, les états de reçu et leurs transitions, et ce qu’un récepteur fait d’un message avant que son modèle ne le voie.

Un programme Node n’a pas besoin d’écrire tout cela à la main : @qwen-code/sdk/peer implémente le contrat. PeerEndpoint.start({ name }) publie l’enregistrement et lie la boîte de réception, list() et send() adressent les sessions par nom, et onMessage reçoit ce qu’elles envoient.