コマンド

本文書では、Qwen Code がサポートするすべてのコマンドについて詳しく説明し、セッションの効率的な管理、インターフェースのカスタマイズ、動作の制御を支援します。

Qwen Code のコマンドは特定のプレフィックスでトリガーされ、次の 3 つのカテゴリに分類されます。

1. スラッシュコマンド (/)

スラッシュコマンドは、Qwen Code のセッション、インターフェース、および基本的な動作を管理するために使用されます。

1.1 セッションとプロジェクトの管理

これらのコマンドは、作業の進捗を保存、復元、および要約するのに役立ちます。

1.2 インターフェースとワークスペースの制御

インターフェースの外観と作業環境を調整するためのコマンド。

1.3 言語設定

インターフェースと出力言語を制御するための専用コマンド。

• 利用可能な組み込み UI 言語: zh-CN (簡体字中国語)、en-US (英語)、ru-RU (ロシア語)、de-DE (ドイツ語)、ja-JP (日本語)、pt-BR (ポルトガル語 - ブラジル)、fr-FR (フランス語)、ca-ES (カタルーニャ語)
• 出力言語の例: Chinese, English, Japanese など。

1.4 ツールとモデルの管理

AI ツールとモデルを管理するためのコマンド。

1.5 組み込みスキル

これらのコマンドは、特殊なワークフローを提供するバンドルされたスキルを呼び出します。

完全な/reviewドキュメントについてはCode Reviewを、/autofix-prについてはAutofix a Pull Requestを参照してください。

1.6 サイドクエスチョン (/btw)

/btw コマンドを使用すると、メインの会話フローを中断したり影響を与えたりすることなく、簡単なサイドクエスチョン（脇道に逸れた質問）を行うことができます。

動作の仕組み:

• サイドクエスチョンは、最近の会話コンテキスト（最大20メッセージまで）を含む別の API コールとして送信されます。
• 応答は 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 コマンドは、これまでの会話の独立した読み取り専用のレビューを実行し、構造化されたセカンドオピニオンを返します。タスクを実行したり、メインの会話を中断したりすることはありません。

動作の仕組み:

• レビューは、最近の会話コンテキスト（最大40メッセージ）を含む、独立した単一ターンのAPIコールとして送信されます
• レビュアーモデルはツールを実行できません — ツールはリストレベルで削除されます（/btw と同じメカニズム）。そのため、レビューがコードを書いたりコマンドを実行したりすることはありません。すべての主張は表示されているトランスクリプトに根ざしている必要があります
• メインの会話は中断されません。レビューはあなたにのみ表示されます
• レビューは、/advisor · <model> ヘッダーの下に4つの固定セクション — Verdict、Risks、Missing evidence、Recommendation — を持つ枠付きMarkdownブロックとしてレンダリングされます。ヘッダーには解決されたレビュアーモデル名が表示されます
• /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 モデルが設定されていない場合の fast）のみ、メインモデルにフォールバックします。アドバイザーリクエストは設定されたモデルフォールバックを使用しません。

サポートされる実行モード:

1.8 セッションリキャップ (/recap)

/recapコマンドは、現在のセッションの「どこまで進んだか」を示す短い要約を生成します。これにより、履歴をスクロールせずに古い会話を再開できます。

動作の仕組み:

• 設定済みの高速モデル（fastModel設定）が利用可能な場合はそれを使用し、そうでない場合はメインのセッションモデルにフォールバックします。振り返りには小さく安価なモデルで十分です。
• 直近の会話（最大30メッセージ、テキストのみ — ツール呼び出しとツール応答は除外されます）が、厳密なシステムプロンプトとともにモデルに送信されます。
• 要約は暗い色調で表示され、❯プレフィックスが付与されるため、実際のアシスタント返信と区別しやすくなります。
• モデルのターンが実行中または他のコマンドが処理中の場合、インラインエラーで拒否されます。使用可能な会話がない場合や、基盤となる生成が失敗した場合は、要約の代わりに/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 でインライン diff を表示します。

動作の仕組み:

インタラクティブモードでは、/diff は上部にソースピッカーを持つダイアログを開きます。

• Current — ワーキングツリーと HEAD の比較（git diff HEAD）。ステージング済み、ステージング解除済み、未追跡ファイルを含む、すべての未コミットの変更を表示します。
• T1, T2, T3, … — ターンごとの diff。ファイルを変更したモデルターンごとに1つのタブがあります。最新のターンが最初に表示されます。各タブには、コンテキストとして元のプロンプトのプレビューが表示されます。

ファイルリストには、ファイルごとの統計情報（追加/削除された行数）と、特別な状態（new、deleted、untracked、binary、truncated、oversized）のタグが表示されます。ファイル上で Enter を押すと、構文ハイライトされた hunk でインライン 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                     │
└─────────────────────────────────────────────────────────────────────┘

非インタラクティブモード:

ヘッドレス（--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）を切り替えることができます。

History Viewer (/log) — Web Shell のみ

/log コマンドは、現在のワークスペースのコミット履歴ブラウザを開きます。Web Shell UI でのみ利用可能で、CLI/TUI にはこのコマンドはありません。

動作の仕組み:

/log はコミットを時系列の逆順（新しい順）で一覧表示するダイアログを開きます。各行には以下が表示されます。

• 短い SHA（モノスペース、フル SHA のコピーボタン付き）
• コミット件名（1行）
• 作成者名と相対時間（例: 「2h ago」）
• ブランチ/タグの参照ラベル（存在する場合）
• マージコミットのマージアイコン（⎇）

コミット行をクリックすると、詳細がオンデマンドで展開されます。

• 完全なコミットメッセージ本文
• ファイル変更統計（変更ファイル数、追加/削除行数、ファイルごとの内訳）

下部の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 認証コマンド

Qwen Code セッション内で /auth を使用して認証を設定します。現在の認証と環境のステータスを確認するには /doctor を使用します。

2. @ コマンド（ファイルの導入）

@ コマンドは、ローカルファイルやディレクトリの内容を会話に素早く追加するために使用します。

注: パス内のスペースはバックスラッシュでエスケープする必要があります（例: @My\ Documents/file.txt）

インタラクティブプロンプトでは、@補完がUnicodeファイル名（絵文字を含む）をサポートしています。プロンプト内の他の場所にある絵文字は、補完に使用されるファイルパスを変更しません。

3. 感嘆符コマンド（!） - シェルコマンドの実行

感嘆符コマンドを使用すると、Qwen Code 内で直接システムコマンドを実行できます。

環境変数: ! を介して実行されるコマンドには、QWEN_CODE=1 環境変数が設定されます。

4. カスタムコマンド

頻繁に使用するプロンプトをショートカットコマンドとして保存し、作業効率と一貫性を向上させます。

概要

優先順位ルール: プロジェクトコマンド > ユーザーコマンド（名前が同じ場合はプロジェクトコマンドが使用されます）

コマンドの命名規則

ファイルパスからコマンド名へのマッピングテーブル

命名規則: パス区切り文字（/ または \）はコロン（:）に変換されます。

Markdownファイル形式仕様（推奨）

カスタムコマンドは、オプションのYAMLフロントマター付きのMarkdownファイルを使用します:

---
description: Optional description (displayed in /help)
---
 
Your prompt content here.
Use {{args}} for parameter injection.

TOML ファイル形式（非推奨）

パラメータ処理メカニズム

1. コンテキスト認識注入（{{args}}）

2. デフォルトパラメータ処理

🚀 動的コンテンツ注入

3. シェルコマンドの実行（!{...}）

例: Gitコミットメッセージ生成

---
description: Generate Commit message based on staged changes
---
 
Please generate a Commit message based on the following diff:
 
```diff
!{git diff --staged}
```

4. ファイル内容の注入（@{...}）

例: コードレビューコマンド

---
description: Code review based on best practices
---
 
Review {{args}}, reference standards:
 
@{docs/code-standards.md}

実用的な作成例

「純関数リファクタリング」コマンド作成手順表

---
description: Refactor code to pure function
---
 
Please analyze code in current context, refactor to pure function.
Requirements:
 
1. Provide refactored code
2. Explain key changes and pure function characteristic implementation
3. Maintain function unchanged

カスタムコマンドベストプラクティスまとめ

コマンド設計推奨事項表

セキュリティ機能リマインダー表

5. CLI サブコマンド

これらのコマンドは、インタラクティブセッションを開始する前に、シェルから qwen <subcommand> として実行されます。

セッション管理

qwen sessions list

メタデータを含む最近の Qwen Code セッションを一覧表示します。

フラグ:

人間が読みやすい出力（デフォルト）:

以下の列を持つテーブル: SESSION ID, STARTED (UTC タイムスタンプ), TITLE, BRANCH, PROMPT.

JSON 出力 (--json):

stdout に JSON Lines を出力します。各行は以下のフィールドを持つ JSON オブジェクトです。

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

「これ以降にセッションがある」ことを示すヒントは stderr に出力されるため、jq にパイプしても安全です。

例:

# Show last 20 sessions (default)
qwen sessions list
 
# Show last 50 sessions
qwen sessions list --limit 50
 
# Output as JSON for scripting
qwen sessions list --json | jq .

qwen sessions ps

このマシンで可視化されているQwen Codeセッションレコードを一覧表示します。sessions listは保存されたトランスクリプト（「自分が何に取り組んできたか」）を走査します。このコマンドは、ライブプロセスレジストリとmanagedとしてマークされたAgent Viewレコードの両方を表示します。強制終了されたセッションが残したレコードは、検出時にレジストリから削除されます。管理対象レコードは永続的な記録であり、そのワーカーが生きていることの証拠ではありません。ワンショットのqwen -p実行は登録されず、表示もされません。

フラグ:

人間が読みやすい出力（デフォルト）:

NAME, KIND, PID, AGE, DIRECTORY の列を持つテーブルです。

KINDはセッションを登録したものを示します — ターミナルでの操作ならtui、Qwen Codeセッションではないプログラム（音声フロントエンド、リレーなど）ならexternal、別のプログラムが駆動するセッションならheadlessまたはserveです。複数のserveまたはheadless行が同じPIDを共有することがあります。qwen --acpの子プロセスはすべてのセッションを1つのプロセス内でホストしており、デーモンが起動した場合serve、クライアントが直接駆動している場合headlessとなり、ピアメッセージングがアクティブな場合はそれぞれ個別に登録されます。ホストされたセッションは、自身の環境がベアモードまたはセーフモードにある場合、ここでは登録されません。デーモンの--bareは、それがホストするセッションには届きません（QWEN_CODE_SIMPLEは子環境から除去されます）。継承されたQWEN_CODE_SAFE_MODEは届き、これらのホストされたセッションがこの一覧に表示されないようにします。これはNAMEやDIRECTORYと同様の自己申告です。ここにあるすべてのフィールドは、記述対象のプロセスによって書き込まれたものであり、セッションが許可されていることに関する情報は含まれていません。managedとしてマークされたAgent Viewレコードは、KINDにmanaged、PIDとAGEに-を使用します。同じセッションにライブレジストリレコードがある場合でも、それは別の行として残ります。レコード形式や独自プログラムの登録方法については、Cross-Session Protocolを参照してください。

JSON 出力 (--json):

stdoutにJSON Linesを出力し、管理対象レコードを最初に配置します。レジストリレコードは既存の形状を維持します。

schemaVersion, pid, procStart, pidNs, sessionId, cwd, name, startedAt,
qwenVersion, kind, ipcPath (when peer messaging is available)

管理されたレコードには、ソースに基づくデータのみが含まれます：

sessionId, cwd, managed: true

stdoutには何も書き込まれません — 空の一覧は何も出力しません — そのため、qwen sessions ps --json | jq .はスクリプトから安全に使用できます。スーパーバイザーストアを読み取れない場合でも、レジストリレコードは出力され、理由はstderrに書き込まれます。

JSON出力は生データです。フィールド値は記録されたままの状態で出力され、ターミナル用のサニタイズは行われません。これらをデータとして扱い、ターミナルでレンダリングする前にサニタイズしてください。

例:

# Show the other live sessions
qwen sessions ps
 
# Which directories have a visible session record?
# Note: `jq -r` renders the raw recorded value in your terminal (see the
# raw-data note above); pipe through a sanitizer if the path is untrusted.
qwen sessions ps --json | jq -r .cwd

6. 他の実行中セッションへのメッセージ送信

同じマシン上の2つのインタラクティブセッションは互いにメッセージを送受信できます。この機能はデフォルトで有効ですが、--bareと--safe-modeは設定に関係なく無効化します。受信用インボックスがあれば、セッションは同じユーザーの他のセッションから検出可能になり、それらが送る内容はモデルが見る前に以下のレビュールールを経由します。ピア検出とメッセージングを無効にするには、settings.jsonでオフにして再起動してください。

{ "agents": { "crossSessionMessaging": false } }

ピアメッセージングが無効なインタラクティブセッションはqwen sessions psに表示される場合がありますが、ipcPathを持たず、list_agentsでは到達可能なピアではありません。OpenTUIインターフェースもピアインボックスをバインドしません。設定を有効にするだけでは、メッセージング可能にはなりません。

メッセージングが有効な場合、あるセッション内のモデルは list_agents を使用して他のセッションを検出できます。各セッションは sessions の下に name とともに表示され、これは qwen sessions ps --json が記録するものです（テーブルビューでは長い名前が省略される場合があります）。その名前を to として send_message を使用して特定のセッションに宛先指定します。2つのセッションが同じ名前を共有する場合、list_agents はそれぞれに短い [ref] を付けて表示し、送信時にはこれを含める必要があります（name [ref]）。どちらの意味にもなり得る裸の名前は推測されるのではなく拒否されます。list_agents はまた、self の下でセッション自身の名前も報告し、to: "*" は依然として「自分の Agent Team のチームメイト」を意味し、他のセッションには届きません。

メッセージは、ユーザーからのものではなく、別のセッションからのものであるとマークされて他のセッションに到着し、そこでのあなたの権限は一切持ちません。受信セッションは、独自の許可設定の範囲内でのみそれに対応します。そのユーザーは agents.crossSessionInbound （accept、hold、または refuse）を使用して、受信メッセージに対する処理を選択できます。未設定の場合、両方のセッションが同じレビュークラスにある場合にのみメッセージが配信されます。つまり、両方とも各アクションをレビューしている場合（デフォルトまたはプランモード）、または両方ともアクションごとのレビューなしで一部のアクションを適用するモード（auto-edit、auto、または yolo）にある場合です。別のクラスのセッションからのメッセージ、または自分がどのクラスにいるかを示さない送信者からのメッセージは、双方向でレビューのために保留されます。各アクションをレビューするセッションは、レビューしないセッションからのメッセージを保留します。なぜなら、そのメッセージは誰も監視していないモデルによって作成されたものであり、アクションごとのプロンプトはアクションを保護するためのものであって、セッションが何に説得されているかを保護するものではないからです。保留されたメッセージは、受信セッションで /peers を使用して一覧表示および解放され、モードの違いのみで保留されたメッセージは、モードが一致すると自動的に解放されます。

リポジトリは、その中で開かれたセッションをより慎重にすることはできますが、より寛容にすることはできません。ワークスペースの .qwen/settings.json は、agents.crossSessionInbound を hold または refuse に設定したり、agents.crossSessionMessaging を false に設定したりでき、その値はユーザー設定内のより緩い値よりも優先されます。オペレーターが設定した値を緩和しようとするワークスペースの値（accept、またはユーザーまたはシステムスコープでスイッチが false に設定されている場合の true）は、警告とともに無視されます。他にスイッチを設定していない場所でのワークスペースの true は単にデフォルトを繰り返すだけで、静かに破棄されます。CLI が認識できない値は、それが有効な値である限りすべてのメッセージを保留します。システム設定は、すべての設定と同様に、これらすべてを上書きします。

保留は永遠に待ちません。誰も決定しないメッセージは agents.crossSessionHeldExpiry 後に期限切れになります — 1m、5m、10m、または never で、デフォルトでは5分です — そして送信セッションには決定が来なかったことが通知されます。この設定を短くすることは、すでに待機中のメッセージにも適用されます。

セッションが受信箱をバインドできない場合 — ランタイムディレクトリが存在しない、他のユーザーが所有している、または読み取り専用である場合（コンテナ内で発生することがあります）— まず一時ディレクトリ下のプライベートディレクトリを試み、それも失敗した場合のみ受信箱なしで起動します。その場合、セッションは起動時にその旨を伝え、/peers が理由と変更すべきこと（通常は XDG_RUNTIME_DIR または TMPDIR）を繰り返します。

アドレスはプロセスIDでキー付けされており、ランタイムディレクトリを共有するコンテナ間でプロセスIDが重複するため、2つのセッションが同じ受信箱アドレスを解決することも可能です。2番目に起動するセッションは、使用中のアドレスを奪う代わりに隣接するアドレスを取得するため、どちらも到達不能になることはありません。ピアは影響を受けません。ピアはセッションのアドレスを導出するのではなく、セッションレジストリから読み取ります。

send_message 呼び出しは、メッセージが他のセッションに渡されたことを確認するだけです。その後どうなったかは、レシートとして後で届きます。保留、拒否、却下、破棄、期限切れ、誤った宛先（アドレスが変わった場合 — エージェントを再リストしてください）— または保留後の解放 — のいずれかの場合、通知が送信セッションのトランスクリプトに表示されます（Message to <name>: …）。拒否、却下、破棄は3つの異なる回答です。拒否は誰かがメッセージをレビューして「いいえ」と言ったことを意味し、却下はそのセッションの agents.crossSessionInbound が refuse であり誰も見ていなかったことを意味し、破棄はそれ以前に受信箱がメッセージを弾いたことを意味します（下記参照）。最初の破棄は即座に応答され、残りは数秒ごとにレシートにまとめられ、それぞれが代表するメッセージを名指しするため、連続した破棄は1行ずつではなく数行のコストで済みます。送信したモデルには通知されません。他のセッションが返信した場合、返信はクロスセッションメッセージとして届きます。

フラッド対策

セッションは、1人の送信者から一度に最大30件のメッセージを受け入れ、その後は2秒ごとに1件まで受け入れます。また、すべての送信者から合わせて一度に最大32件を受け入れ、その後は1秒ごとに1件まで受け入れます。2番目の制限が存在するのは、送信者が自身の名前を指定するためです。名前をローテーションすると最初の制限からは新しい許容量が得られますが、2番目の制限からは得られません。この値が最初の制限よりわずかに高いのは、受け入れられた各メッセージが受領証を発行し、セッションが同時に発行できる受領証の数には上限があるためです。別のセッションからのメッセージで、同じ送信者の直前のメッセージと完全に一致する内容が30秒以内に届いた場合も拒否されます。モデルが一文をループしている場合、毎回新しいメッセージIDが発行されるため、テキストの一致によって検出されます。セッションが起動したスクリプトからのメッセージや信頼されたコントローラーからのメッセージは重複チェックの対象外です。フックが同じ行を2回報告することは2つの事実を報告することであり、人が「続行」と2回言うことは2回の指示を意味するためですが、これらもレート制限の対象となります。最後に、メッセージは受け入れられたものの、セッションに既に50件の待機中のメッセージがありキューに入れられない場合も拒否されます。

この方法で拒否されたメッセージは保持されず、モデルに表示されることもなく、記録も残らないため、送信者は後で再試行して成功させることができます。受信セッションは、その旨をトランスクリプトに送信者あたり1分間に最大1回表示し、その行が何を表すかの件数を記載します。送信セッションには、バーストによって失われたすべてのメッセージを列挙した1件の受領証が届き、トランスクリプトには、再度送信するのではなく、重要な内容を後の1件のメッセージにまとめるよう指示されます。

送信側は結果を待ちません。各セッションは、各アドレスに送信した内容を追跡し、受信側が破棄するような送信を拒否するため、モデルにはメッセージを書き込む前にバッチ処理を行うよう指示されます（書き込み後ではありません）。また、受信側は拒否予定のメッセージに対して接続を消費しません。

Inbox認証とスクリプトによる注入

各セッションの受信箱には、セッション固有のトークンが必要です。接続は、メッセージを読み取る前に最初の行でこのトークンを提示しなければなりません。セッション同士は、互いを発見するために使用する同じレジストリレコードを通じて、自動的にトークンを交換します。トークンサポートのないビルドからのセッションは、新しいビルドからのメッセージを受信できますが、新しいビルドへの送信は破棄されます。

セッションは、自身の受信箱アドレスとトークンを子プロセスへ環境変数 QWEN_CODE_MESSAGING_SOCKET と QWEN_CODE_MESSAGING_TOKEN としてエクスポートします。これにより、セッションが実行するスクリプトやフックからセッションへメッセージを送り返すことができます。これは child トークンと呼ばれ、どこにも公開されない第2のトークンです。セッションが起動したプロセスのみがこのトークンを保持できるため、このトークンとともに届いたメッセージは、他のセッションからのものではなく、セッション自身のものとして認識されます。

{ 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 を与えてください。受信ゲートはすでに処理済みのIDを記憶しているため、IDを再利用するフックは初回は配信されますが、それ以降の実行では静かに重複排除されます。同じ テキスト を繰り返すことは問題ありません。上記の重複チェックはセッション自身のプロセスには適用されないためです。ただし、レート制限は適用されるため、ループ内のフックは他の洪水と同様に破棄されます。

注入されたメッセージは依然としてインバウンドゲートを通過し、ユーザー由来ではないとマークされますが、ゲートはそれがセッション自身のプロセス由来であることを認識しています。デフォルトのモード整合性ルール下では、レビューなしで配信されます（同位置のピアであれば保留されます）が、agents.crossSessionInbound に hold または refuse を明示的に設定した場合、他のメッセージと同様に適用されます。モデルはこれを <cross_session_message from="own process" origin="own-process"> として認識し、ユーザー由来ではなく、セッションが実行したスクリプトまたはフック由来であるという通知が表示されます。

信頼できるコントローラー

上記のルールは、どのレビュークラスに属するかを指定しないあらゆる送信者からのメッセージを保留します。Qwen Codeセッションではないプログラムは、レビュークラスを指定できません。これは見知らぬ相手に対する正しいデフォルトですが、あなたが選択したプログラムに対しては適切ではありません。音声フロントエンド、ディクテーションブリッジ、あなたの指示を中継する自動化デーモンなどは、すべてのメッセージが保留されてしまい、一つずつ手動で承認することは目的に反します。

そのようなプログラムにトークンを発行することで配信を許可します:

qwen sessions controllers add --label voice-bridge

トークンは一度だけ表示され、どこにも保存されません。Qwenホーム下のファイルには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ホームに属するため、コントローラーは実行中の任意のセッションに到達できます。セッションは接続ごとにファイルを再読み込みするため、許可の作成または取り消しは次の接続時に有効になり、再起動は不要です。

qwen sessions controllers list          # ids, labels, when they were added
qwen sessions controllers remove c_1a2b # revoke one

セッション内では /peers controllers と /peers revoke <id> が同じ機能を提供します。権限付与を介して届いたメッセージは Message from a trusted controller (voice-bridge) として表示され、hold 設定によって保留された場合は /peers に [controller] voice-bridge として現れます。

モデルはこの種のメッセージを <cross_session_message from="controller" origin="controller" controller="voice-bridge"> として認識し、これがユーザー自身の指示を中継している旨の通知が付随します。他のすべての送信元と同様に、次の2つの禁止事項が適用されます。メッセージの要求により権限設定や QWEN.md、または config を編集することはできません。また、保留中の確認プロンプトに対するユーザーの承認としてメッセージを扱うこともできません。コントローラーは次に実行すべきことを指示できますが、ユーザーに代わってプロンプトに回答することはできません。

トークンを保有する者は誰でもそのコントローラーとして送信できるため、他の認証情報と同様に扱ってください。単一のプログラムにのみ提供し、共有設定には含めず、そのプログラムの処理が完了したら取り消してください。

ACP 経由でプログラムが駆動するセッション

任意の qwen --acp 子プロセスは、自身がホストする各セッションを登録します。デーモンがプロセスを起動した場合は serve として、エディターや他のクライアントが qwen --acp を直接制御している場合は headless として登録されます。これらのセッションは qwen sessions ps や他のセッションの list_agents に、通常のセッションと同様に表示されます。送信も可能で、モデルは send_message を呼び出して開いているターミナルに到達できます。複数のセッションが1つのプロセスと1つの受信箱を共有するため、送信者は意図したセッションを指定する必要があります。Qwen Code のすべてのセッションはこの処理を自動的に実行します。

制御されているセッションへのメッセージは、保留されるのではなく拒否されます。保留は人間に対する質問であり、制御されているセッションのために保留メッセージリストを確認している人はいません。送信者は期限切れを待たずに即座に通知を受けます。これらのセッションにおいて保留メッセージをどこに表示すべきかは、まだ決定されていません。

セッションは、自らの設定で agents.crossSessionMessaging がオフになっている場合や、--bare または --safe-mode で起動された場合を除いて登録されます。これらは設定に関係なくメッセージ機能を無効化します。無効化された場合、セッションは不可視のままとなります。誰もメッセージを送れないセッションを一覧に表示する唯一の理由は、応答しないアドレスを宣伝することになるためです。

Qwen Code セッションではないプログラム

上記の機能はすべてセッション間で動作しますが、いずれも特定のセッションに依存するものではありません。レジストリレコードを作成し、同様に受信箱をバインドするプログラムは、qwen sessions ps および list_agents によって一覧表示され、send_message から名前でアドレス指定でき、送信内容に対する配信領収書を受け取ります。これは音声フロントエンド、リレー、ビルドウォッチャーなどが該当します。一覧表示で内容を説明できるように、kind: "external" を記録しておくべきです。

クロスセッションプロトコル は、それを実装するための契約です。レコードスキーマと生存性判定方法、ソケットパスとフレーミング、認証行、すべてのフレームフィールド、領収書の状態とその遷移、そしてモデルがメッセージを見る前に受信者が行う処理について定義されています。

Node プログラムはこれらの実装を手作業で行う必要はありません。@qwen-code/sdk/peer がこの契約を実装しています。PeerEndpoint.start({ name }) はレコードを公開し受信箱をバインドし、list() と send() は名前でセッションをアドレス指定し、onMessage はそれらから送信されたものを受信します。