Команды

В этом документе подробно описаны все команды, поддерживаемые Qwen Code, которые помогут вам эффективно управлять сессиями, настраивать интерфейс и контролировать его поведение.

Команды Qwen Code вызываются с помощью специальных префиксов и делятся на три категории:

1. Slash-команды (/)

Slash-команды используются для управления сессиями, интерфейсом и базовым поведением Qwen Code.

1.1 Управление сессиями и проектами

Эти команды помогают сохранять, восстанавливать и резюмировать ход работы.

1.2 Управление интерфейсом и рабочим пространством

Команды для настройки внешнего вида интерфейса и рабочей среды.

1.3 Настройки языка

Команды для управления языком интерфейса и языком вывода.

• Доступные встроенные языки интерфейса: zh-CN (упрощенный китайский), en-US (английский), ru-RU (русский), de-DE (немецкий), ja-JP (японский), pt-BR (португальский - Бразилия), fr-FR (французский), ca-ES (каталанский)
• Примеры языков вывода: Chinese, English, Japanese и т.д.

1.4 Управление инструментами и моделями

Команды для управления ИИ-инструментами и моделями.

1.5 Встроенные skills

Эти команды вызывают встроенные skills, которые предоставляют специализированные рабочие процессы.

Полную документацию по /review см. в разделе Code Review.

1.6 Побочные вопросы (/btw)

Команда /btw позволяет задавать быстрые побочные вопросы, не прерывая и не влияя на основной ход диалога.

Как это работает:

• Побочный вопрос отправляется как отдельный API-запрос с контекстом недавнего диалога (до последних 20 сообщений)
• Ответ отображается над Composer — вы можете продолжать печатать во время ожидания
• Основной диалог не блокируется — он продолжается независимо
• Ответ на побочный вопрос не становится частью истории основного диалога
• Ответы отображаются с полной поддержкой Markdown (блоки кода, списки, таблицы и т. д.)

Горячие клавиши (Интерактивный режим):

Пример:

(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)

Поддерживаемые режимы выполнения:

1.7 Второе мнение (/advisor)

Команда /advisor выполняет независимое ревью текущего диалога только для чтения и возвращает структурированное второе мнение — не выполняя задачу и не прерывая основной диалог.

Как это работает:

• Ревью отправляется как отдельный одноходовый API-запрос с контекстом недавнего диалога (до последних 40 сообщений)
• Модель-ревьюер не может выполнять инструменты — инструменты удаляются на уровне запроса (тот же механизм, что и для /btw), поэтому ревью никогда не пишет код и не выполняет команды; каждое утверждение должно основываться на видимом транскрипте
• Основной диалог не прерывается; ревью показывается только вам
• Ревью отображается как обрамлённый markdown-блок с четырьмя фиксированными разделами — Verdict, Risks, Missing evidence и Recommendation — под заголовком /advisor · <model>, указывающим используемую модель-ревьюера
• В отличие от /btw, который выполняется fire-and-forget и не блокирует сессию, /advisor блокирует ввод до возврата ревью; при полном окне контекста с мощной моделью-ревьюером это может занять десятки секунд
• По умолчанию используется основная модель; установите advisorModel, чтобы направить ревью на другую (обычно более мощную) модель — недавний транскрипт отправляется этой модели, даже если она использует другого провайдера

Пример:

> /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.                                      │
  ╰──────────────────────────────────────────────────────╯

Ревью отображается в обрамлённом блоке, заголовок которого указывает используемую модель-ревьюера. Неизвестная advisorModel не проверяется заранее — если провайдер отклоняет её, /advisor сообщает о сбое, поэтому проверяйте имя модели; только неразрешимые селекторы алиасов (например, fast без настроенной быстрой модели) откатываются на основную модель. Запросы advisor не используют настроенные фолбэки моделей.

Поддерживаемые режимы выполнения:

1.8 Краткое содержание сессии (/recap)

Команда /recap генерирует короткое резюме «на чем вы остановились» для текущей сессии, чтобы вы могли возобновить старый диалог, не прокручивая страницы истории.

Как это работает:

• Использует настроенную быструю модель (настройка fastModel), если она доступна, иначе переключается на основную модель сессии. Для резюме достаточно небольшой и дешевой модели.
• Недавний диалог (до 30 сообщений, только текст — вызовы инструментов и ответы фильтруются) отправляется модели с кратким системным промптом.
• Резюме отображается приглушенным цветом с префиксом ❯, чтобы отличаться от обычных ответов ассистента.
• Откажется с inline-ошибкой, если выполняется ход модели или обрабатывается другая команда. Если нет подходящего диалога или базовая генерация завершается сбоем, /recap покажет короткое информационное сообщение вместо резюме — ручная команда всегда что-то отвечает.

Автозапуск при возвращении:

Если терминал находится не в фокусе более 5 минут, а затем снова получает фокус, резюме генерируется и отображается автоматически (только если ответ модели не находится в процессе выполнения; иначе команда ждет завершения текущего хода). В отличие от ручной команды, автозапуск полностью молчит при сбое: если генерация завершается ошибкой или нечего резюмировать, сообщение в историю не добавляется. Управляется настройкой general.showSessionRecap (по умолчанию: false); ручная команда /recap всегда работает независимо от этой настройки.

Пример:

> /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 Просмотр diff (/diff)

Команда /diff открывает интерактивный просмотрщик diff, показывающий незакоммиченные изменения и diff для каждого хода. Используйте ←/→ для переключения между текущим git diff и отдельными ходами диалога, ↑/↓ для навигации по файлам и Enter для просмотра inline-diff.

Как это работает:

В интерактивном режиме /diff открывает диалоговое окно с выбором источника в верхней части:

• Current — рабочее дерево против HEAD (git diff HEAD). Показывает все незакоммиченные изменения, включая проиндексированные, непроиндексированные и неотслеживаемые файлы.
• T1, T2, T3, … — diff для каждого хода, по одной вкладке на каждый ход модели, изменивший файлы. Самые последние ходы отображаются первыми. Каждая вкладка показывает превью исходного промпта для контекста.

Список файлов отображает статистику по каждому файлу (добавленные/удаленные строки) с тегами для специальных состояний (new, deleted, untracked, binary, truncated, oversized). Нажмите Enter на файле, чтобы просмотреть его inline-diff с подсветкой синтаксиса для блоков изменений.

Diff для каждого хода требует включения контрольных точек файлов (по умолчанию включено в интерактивном режиме). Когда контрольные точки файлов отключены, доступен только источник “Current”.

Горячие клавиши:

Пример:

┌ /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                     │
└─────────────────────────────────────────────────────────────────────┘

Неинтерактивный режим:

В headless-режиме (--prompt) или неинтерактивном контексте /diff выводит текстовое резюме рабочего дерева против HEAD. Навигация по ходам недоступна.

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

Web Shell: В Web Shell UI (qwen serve), /diff открывает графический диалог diff. Панель вкладок в верхней части позволяет переключаться между представлением Changes и представлением History (/log).

Просмотр истории (/log) — только Web Shell

Команда /log открывает браузер истории коммитов для текущего рабочего пространства. Она доступна только в Web Shell UI; CLI/TUI не имеет этой команды.

Как это работает:

/log открывает диалоговое окно со списком коммитов в обратном хронологическом порядке (новые первые). Каждая строка показывает:

• Короткий SHA (моноширинный, с кнопкой копирования полного SHA)
• Тему коммита (одна строка)
• Имя автора и относительное время (например, “2h ago”)
• Метки ссылок веток/тегов, если есть
• Иконку слияния (⎇) для merge-коммитов

Нажмите на строку коммита, чтобы развернуть его детали по запросу:

• Полное тело сообщения коммита
• Статистику изменений файлов (изменённые файлы, добавленные/удалённые строки, разбивка по файлам)

Используйте Load more внизу, чтобы загрузить следующую страницу коммитов (50 на страницу).

Пример:

┌─ 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 Информация, настройки и помощь

Команды для получения информации и выполнения системных настроек.

1.11 Часто используемые сочетания клавиш

1.12 Команды аутентификации

Используйте /auth внутри сессии Qwen Code для настройки аутентификации. Используйте /doctor для проверки текущего статуса аутентификации и состояния окружения.

2. Команды @ (Подключение файлов)

Команды @ используются для быстрого добавления содержимого локального файла или директории в контекст разговора.

Примечание: Пробелы в путях необходимо экранировать обратным слешем (например, @My\ Documents/file.txt).

3. Команды с восклицательным знаком (!) — Выполнение Shell-команд

Команды с восклицательным знаком позволяют выполнять системные команды непосредственно внутри Qwen Code.

Переменные окружения: При выполнении команд через ! устанавливается переменная окружения QWEN_CODE=1.

4. Пользовательские команды

Сохраняйте часто используемые промпты в виде команд быстрого доступа для повышения эффективности работы и обеспечения согласованности.

Краткий обзор

Правила приоритета: Команды проекта > Пользовательские команды (при совпадении имен используется команда проекта).

Правила именования команд

Таблица сопоставления пути к файлу и имени команды

Правила именования: Разделитель пути (/ или \) преобразуется в двоеточие (:).

Спецификация формата Markdown-файлов (Рекомендуется)

Пользовательские команды используют Markdown-файлы с опциональным YAML frontmatter:

---
description: Опциональное описание (отображается в /help)
---
 
Здесь ваш текст промпта.
Используйте {{args}} для внедрения параметров.

Формат TOML-файлов (Устарел)

Механизм обработки параметров

1. Контекстное внедрение ({{args}})

2. Обработка параметров по умолчанию

🚀 Внедрение динамического контента

3. Выполнение Shell-команд (!{...})

Пример: Генерация сообщения для Git-коммита

---
description: Генерация сообщения коммита на основе проиндексированных изменений
---
 
Пожалуйста, сгенерируй сообщение коммита на основе следующего diff:
 
```diff
!{git diff --staged}
```

4. Внедрение содержимого файлов (@{...})

Пример: Команда для Code Review

---
description: Code review на основе лучших практик
---
 
Проведи ревью {{args}}, эталонные стандарты:
 
@{docs/code-standards.md}

Практический пример создания

Таблица шагов создания команды “Рефакторинг в чистую функцию”

---
description: Рефакторинг кода в чистую функцию
---
 
Пожалуйста, проанализируй код в текущем контексте и выполни рефакторинг в чистую функцию.
Требования:
 
1. Предоставь рефакторенный код
2. Объясни ключевые изменения и реализацию характеристик чистой функции
3. Сохрани функциональность без изменений

Сводка лучших практик для пользовательских команд

Таблица рекомендаций по проектированию команд

Таблица напоминания о функциях безопасности

5. Подкоманды CLI

Эти команды выполняются из shell как qwen <subcommand> перед началом интерактивной сессии.

Управление сессиями

qwen sessions list

Выводит список ваших недавних сессий Qwen Code с метаданными.

Флаги:

Человекочитаемый вывод (по умолчанию):

Таблица со столбцами: SESSION ID, STARTED (UTC-время), TITLE, BRANCH, PROMPT.

JSON-вывод (--json):

Выводит JSON Lines в stdout. Каждая строка представляет собой JSON-объект с полями:

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

Подсказка о наличии дополнительных сессий выводится в stderr, чтобы конвейеризация в jq оставалась безопасной.

Примеры:

# Показать последние 20 сессий (по умолчанию)
qwen sessions list
 
# Показать последние 50 сессий
qwen sessions list --limit 50
 
# Вывести в формате JSON для скриптов
qwen sessions list --json | jq .

qwen sessions ps

Выводит список интерактивных сессий Qwen Code, запущенных на этой машине в данный момент. sessions list обходит сохранённые транскрипты («над чем я работал»); эта команда обходит реестр живых процессов («что запущено в данный момент»). Записи, оставшиеся от завершённой сессии, удаляются по мере обнаружения. Headless-сессии (qwen -p) не регистрируются в реестре живых процессов, поэтому не отображаются.

Флаги:

Человекочитаемый вывод (по умолчанию):

Таблица со столбцами: NAME, KIND, PID, AGE, DIRECTORY.

KIND показывает, что зарегистрировало сессию — tui для кого-то за терминалом, external для программы, которая вообще не является сессией Qwen Code (голосовой фронтенд, ретранслятор), и headless или serve для сессии, которой управляет другая программа. Несколько строк serve или headless могут иметь один PID: дочерний процесс qwen --acp размещает все свои сессии в одном процессе — serve, когда его запустил демон, headless, когда клиент управляет им напрямую — и каждая из них регистрируется отдельно. Это самоотчёт, как и NAME, и DIRECTORY: каждое поле здесь записано процессом, который оно описывает, и ничего из того, что сессии разрешено делать, от этого не зависит. См. Cross-Session Protocol для формата записи и регистрации собственной программы.

JSON-вывод (--json):

Выводит JSON Lines в stdout, самые новые сессии первыми. Каждая строка представляет собой JSON-объект с полями:

schemaVersion, pid, procStart, pidNs, sessionId, cwd, name, startedAt,
qwenVersion, kind, ipcPath (когда доступен обмен сообщениями peer)

Ничего другого не записывается в stdout — пустой список не выводит ничего — поэтому qwen sessions ps --json | jq . безопасен для использования в скриптах.

JSON-вывод — это сырые данные: значения полей выводятся точно так, как были записаны, без санитизации для терминала. Обрабатывайте их как данные и санитизируйте перед отображением в терминале.

Примеры:

# Показать другие живые сессии
qwen sessions ps
 
# Какие директории сейчас заняты?
# Примечание: `jq -r` отображает сырое записанное значение в терминале
# (см. примечание о сырых данных выше); пропускайте через санитайзер,
# если путь не является доверенным.
qwen sessions ps --json | jq -r .cwd

6. Обмен сообщениями с другой запущенной сессией

Две интерактивные сессии на одной машине могут обмениваться сообщениями. Эта функция экспериментальная и отключена по умолчанию; включите её в settings.json и перезапустите:

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

После включения модель в одной сессии может обнаруживать другие через list_agents — каждая появляется в sessions с name, который записывает qwen sessions ps --json (табличное представление может обрезать длинные имена) — и адресовать одну через send_message, используя это имя как to. Когда две сессии имеют одинаковое имя, list_agents показывает каждую с коротким [ref], и отправка должна включать его (name [ref]); простое имя, которое может означать любую из них, отклоняется вместо угадывания. list_agents также сообщает имя собственной сессии в self, а to: "*" по-прежнему означает «мои коллеги по Agent Team» и никогда не достигает других сессий.

Сообщение поступает в другую сессию с пометкой, что оно исходит от другой сессии, а не от её пользователя, и не несёт никаких ваших полномочий там: получающая сессия обрабатывает его только в рамках своих собственных настроек разрешений. Её пользователь может выбрать, что происходит с входящими сообщениями, через agents.crossSessionInbound (accept, hold или refuse). Если значение не установлено, сообщение доставляется только когда обе сессии находятся в одном классе проверки: обе по-прежнему проверяют каждое действие (режим default или plan), или обе находятся в режиме, применяющем некоторые действия без проверки каждого действия (auto-edit, auto или yolo). Сообщение из сессии в другом классе или от отправителя, который не указывает, в каком классе он находится, удерживается для проверки — в обоих направлениях. Сессия, проверяющая каждое действие, удерживает сообщение от сессии, которая этого не делает, потому что это сообщение написано моделью, за которой никто не следил, а промпты проверки каждого действия защищают действия, а не то, что сессии предлагают делать. Удержанные сообщения отображаются и освобождаются через /peers в получающей сессии, а сообщение, удержанное только из-за различия режимов, освобождается автоматически, когда режимы совпадают.

Репозиторий может сделать открытые в нём сессии более осторожными, но не менее: workspace .qwen/settings.json может установить agents.crossSessionInbound в hold или refuse, или agents.crossSessionMessaging в false, и это значение имеет приоритет над более мягким в ваших пользовательских настройках. Значение workspace, которое смягчило бы вашу настройку (accept или true для переключателя), игнорируется с предупреждением, а значение, которое CLI не распознаёт, удерживает каждое сообщение, когда оно является эффективным. Системные настройки переопределяют всё это, как и для любой другой настройки.

Удержание не ждёт бесконечно. Сообщение, по которому никто не принял решение, истекает через agents.crossSessionHeldExpiry — 1m, 5m, 10m или never, по умолчанию пять минут — и отправляющая сессия получает уведомление, что решение не было принято. Уменьшение значения применяется уже к ожидающим сообщениям.

Если сессия не может привязать свой inbox — директория runtime отсутствует, принадлежит другому пользователю или доступна только для чтения, как это бывает внутри контейнера — она сначала пробует приватную директорию во временной директории, и только если это тоже не удаётся, запускается без него. Когда это происходит, сессия сообщает об этом при запуске, а /peers повторяет причину и что изменить (обычно XDG_RUNTIME_DIR или TMPDIR).

Две сессии могут также получить один и тот же адрес inbox, потому что адрес привязан к идентификатору процесса, а идентификаторы процессов повторяются в контейнерах, использующих общую директорию runtime. Сессия, запущенная второй, занимает соседний адрес вместо того, чтобы захватить используемый, поэтому ни одна из них не становится недоступной. Peers не затрагиваются: они читают адрес сессии из реестра сессий, а не выводят его.

Вызов send_message только подтверждает, что сообщение передано в другую сессию. Что с ним произошло, приходит позже как квитанция: если оно было удержано, отклонено (declined), отказано (refused), отброшено (dropped), просрочено или неправильно адресовано (адрес сменил владельца — перечислите агентов снова) — или освобождено после удержания — уведомление появляется в транскрипте отправляющей сессии (Message to <name>: …). Declined, refused и dropped — три разных ответа: declined означает, что кто-то проверил сообщение и отклонил, refused означает, что agents.crossSessionInbound этой сессии установлен в refuse и никто его вообще не видел, а dropped означает, что inbox отклонил сообщение до всего этого (см. ниже). Первый отклонённый ответ возвращается сразу, а остальные сворачиваются в квитанцию каждые несколько секунд, каждая с указанием сообщений, которые она представляет, поэтому серия из них занимает несколько строк, а не по одной на каждое. Модель, отправившая его, не уведомляется; если другая сессия отвечает, ответ приходит как межсессионное сообщение.

Защита от флуда

Сессия принимает до 30 сообщений одновременно от одного отправителя, а затем по одному каждые две секунды, и до 32 одновременно от всех отправителей вместе, а затем по одному в секунду. Второй лимит существует потому, что отправитель называет себя: ротация этого имени даёт свежий лимит по первому ограничению, но не по второму. Он лишь немного превышает первый, потому что каждое принятое сообщение генерирует квитанцию, а сессия может отправлять только ограниченное количество таких квитанций за раз. Сообщение из другой сессии, которое дословно повторяет предыдущее сообщение того же отправителя в течение 30 секунд, также отклоняется — модель, зацикленная на одном предложении, каждый раз создаёт новый идентификатор сообщения, поэтому текст — это то, что её ловит. Сообщения из скрипта, запущенного сессией, и от доверенного контроллера освобождены от проверки на повторы, потому что хук, сообщающий одну и ту же строку дважды, сообщает два факта, а человек, говорящий «продолжить» дважды, имеет в виду это дважды; оба всё равно подчиняются ограничениям скорости. Наконец, сообщение, которое принято, но не может быть поставлено в очередь, потому что в сессии уже ожидает 50 сообщений, также отклоняется.

Сообщение, отклонённое таким образом, никогда не удерживается, никогда не показывается модели и не оставляет записи, поэтому отправитель может попробовать позже и преуспеть. Получающая сессия сообщает об этом в своём транскрипте не чаще одного раза в минуту на отправителя, с указанием количества сообщений, которые эта строка представляет. Отправляющая сессия получает одну квитанцию с указанием каждого сообщения, которого стоил этот всплеск, и её транскрипт предлагает свернуть то, что всё ещё важно, в одно последующее сообщение, а не отправлять повторно.

Отправляющая сторона не ждёт, чтобы узнать. Каждая сессия отслеживает, что она отправила на каждый адрес, и отклоняет отправку, которую получатель отбросил бы, поэтому модели говорят группировать до написания сообщения, а не после — и получатель никогда не тратит соединение на сообщение, которое собирался отклонить.

Аутентификация inbox и скриптовые инъекции

Inbox каждой сессии требует токен для каждой сессии: подключение должно представить его в первой строке до чтения любого сообщения, и сессии обмениваются токенами автоматически через те же записи реестра, по которым они обнаруживают друг друга. Сессии из сборки без поддержки токенов могут получать от более новой, но их отправки в неё отбрасываются.

Сессия экспортирует свой адрес inbox и токен дочерним процессам как QWEN_CODE_MESSAGING_SOCKET и QWEN_CODE_MESSAGING_TOKEN, чтобы скрипт или хук, запускаемый сессией, мог отправить сообщение обратно в неё. Это второй, дочерний токен, который нигде не публикуется: только процессы, запущенные сессией, могут его иметь, поэтому сообщение, пришедшее с ним, распознаётся как собственное сообщение сессии, а не другой сессии.

{ 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"

Присваивайте каждой инъекции свежий msgId. Принимающий гейт помнит идентификаторы, которые уже были обработаны, поэтому хук, переиспользующий один и тот же, доставляется в первый раз и тихо дедуплицируется при каждом последующем запуске. Повторение одного и того же текста допустимо — проверка на повторы, описанная выше, не применяется к собственным процессам сессии — но ограничения скорости действуют, поэтому хук в цикле отбрасывается, как любой другой флуд.

Инжектированное сообщение всё равно проходит через входной гейт и помечается как не от пользователя, но гейт знает, что оно пришло из собственного процесса сессии: при стандартном совпадении режимов оно доставляется без проверки (peer в том же положении был бы удержан), тогда как явный agents.crossSessionInbound со значением hold или refuse применяется к нему как к любому другому. Модель видит его как <cross_session_message from="own process" origin="own-process"> с уведомлением, что оно пришло из скрипта или хука, запущенного сессией, а не от пользователя.

Доверенные контроллеры

Правило выше удерживает сообщение от любого отправителя, который не указывает, в каком классе проверки он находится, а программа, не являющаяся сессией Qwen Code, не может этого указать. Это правильный default для незнакомца, но не для выбранной вами программы: голосовой фронтенд, бридж диктанта, демон автоматизации, передающий ваши собственные инструкции, — каждое его сообщение было бы припарковано, а одобрение каждого вручную теряет смысл.

Вы предоставляете такой программе доставку, создавая для неё токен:

qwen sessions controllers add --label voice-bridge

Токен выводится один раз и нигде не хранится: файл в вашем Qwen home хранит только его SHA-256 хеш, поэтому ничто, что позже прочитает этот файл, не сможет представить токен. Поместите его в собственную конфигурацию контроллера, когда команда его выведет.

Контроллер представляет токен так же, как любой другой отправитель — в первой строке подключения — и получает путь к сокету из реестра сессий (qwen sessions ps --json выводит одну запись на каждую живую сессию, ipcPath — это адрес):

{ 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"

Сообщение, пришедшее по предоставленному токену, доставляется без проверки каждого сообщения, в каком бы классе проверки ни находилась любая из сторон — но оно всё равно уступает явной настройке: agents.crossSessionInbound со значением hold удерживает его как любое другое, а refuse отклоняет. Предоставления принадлежат вашему Qwen home, а не одной сессии, поэтому контроллер достигает любых запущенных вами сессий, и сессии перечитывают файл при каждом подключении: создание или отзыв вступают в силу при следующем подключении, без необходимости перезапуска.

qwen sessions controllers list          # идентификаторы, метки, когда они были добавлены
qwen sessions controllers remove c_1a2b # отозвать один

/peers controllers и /peers revoke <id> делают то же самое изнутри сессии. Сообщение, пришедшее через предоставление, отображается как Message from a trusted controller (voice-bridge) и появляется в /peers как [controller] voice-bridge, если настройка hold его припарковала.

Модель видит такое сообщение как <cross_session_message from="controller" origin="controller" controller="voice-bridge"> с уведомлением, что оно передаёт ваши собственные инструкции — и те же два запрета, которые применяются к любому другому источнику: оно не может редактировать настройки разрешений, QWEN.md или конфигурацию по запросу сообщения, и не может рассматривать сообщение как ваше одобрение ожидающего запроса подтверждения. Контроллер может сказать, что делать дальше; он не может ответить на промпт от вашего имени.

Любой, кто владеет токеном, может отправлять от имени этого контроллера, поэтому относитесь к нему как к любым другим учётным данным: выдайте его одной программе, не храните в общей конфигурации и отзовите, когда программа завершит работу.

Сессии, которыми программа управляет через ACP

Любой дочерний процесс qwen --acp регистрирует каждую сессию, которую он размещает — как serve, когда процесс был запущен демоном, как headless, когда редактор или другой клиент управляет qwen --acp напрямую — и сессия появляется в qwen sessions ps и в list_agents другой сессии, как любая другая. Она может отправлять: её модель может вызывать send_message для обращения к терминалу, который вы открыли. Несколько таких сессий используют один процесс и один inbox, поэтому отправитель должен указать сессию, которую имеет в виду — каждая сессия Qwen Code делает это автоматически.

Сообщения, отправленные такой сессии, отклоняются, а не удерживаются. Удержание — это вопрос к человеку, а за списком удержанных сообщений управляемой сессии никто не следит; отправитель получает немедленный ответ вместо ожидания истечения срока. Где должно появляться удержанное сообщение для таких сессий, пока не решено.

Сессия регистрируется только пока в её собственных настройках включено agents.crossSessionMessaging. При выключенной настройке она остаётся невидимой, потому что единственная причина включить в список сессию, которой никто не может отправить сообщение — это рекламировать адрес, который никогда не отвечает.

Программы, не являющиеся сессиями Qwen Code

Всё вышеперечисленное работает между сессиями, но ничего в этом не специфично для одной из них. Программа, которая записывает запись реестра для себя и привязывает inbox тем же способом, отображается в qwen sessions ps и в list_agents, может быть адресована по имени из send_message и получает квитанции о доставке того, что она отправляет — голосовой фронтенд, ретранслятор, наблюдатель за сборкой. Она должна записывать kind: "external", чтобы список мог показать, что это такое.

Cross-Session Protocol — это контракт для написания такой программы: схема записи и как оценивается живучесть, пути сокетов и фрейминг, строка аутентификации, каждое поле фрейма, состояния квитанций и их переходы, и что получатель делает с сообщением до того, как его увидит модель.

Программа на Node не обязана писать всё это вручную: @qwen-code/sdk/peer реализует этот контракт. PeerEndpoint.start({ name }) публикует запись и привязывает inbox, list() и send() адресуют сессии по имени, а onMessage получает то, что они отправляют.