Codexのターミナルから「@」で別タスクを参照──読み取り・作成・メッセージ送信までエージェントに頼める

Codexで複数のタスクを並行して走らせていると、「あのタスクで何をやっていたか」を別のタスクのターミナルから確認したくなる場面がある。0.150.0（2026年8月26日公開）のリリースノートに、この課題に対応した機能が記録されていた。

3行まとめ

• Codex 0.150.0で、TUIから他のCodexタスクを「@」メンションで参照し、一覧・読み取り・作成・フォーク・メッセージ送信・リネーム・アーカイブ/復元・待機できる9種類のツールが追加された
• PR #40308の差分を読むと、実際のツール名はlist_threads・read_thread・create_thread・fork_thread・send_message_to_thread・set_thread_title・set_thread_archivedなど
• create_thread・fork_thread・send_message_to_threadの3つには個別に承認プロンプト（approval_mode: "prompt"）が設定され、list_threads・read_threadなど読み取り系の4つには読み取り専用（read_only）の注釈が付く、という設計がコードから確認できた

Reference other Codex tasks with @ mentions, and ask agents to read, create, or message tasks from the terminal. (#40308, #40315)

（@メンションで他のCodexタスクを参照でき、ターミナルからエージェントにタスクの読み取り・作成・メッセージ送信を依頼できる）

タスク管理用のツール群を丸ごと追加

実装した2本のマージ済みPRの本文を読むと、この機能は単なる参照リンクではなく、タスクを操作するツール群の追加だと分かる。まず#40308の背景と実装内容。

The TUI rejected app-server dynamic tool calls as unsupported, so agents could not inspect or manage other Codex tasks through a TUI session.

• Add the codex_tui tool namespace for listing, reading, waiting on, creating, forking, messaging, renaming, archiving, and restoring tasks.
• Handle tool calls through existing app-server thread operations, with bounded inputs and responses and cleanup when calls complete or the TUI disconnects.
• Route delegation tools through an authenticated local MCP server with explicit approval prompts, while respecting configured and managed MCP policies.
• Fall back to starting threads without dynamic tools when connected to an older app server that does not support them.

（TUIはapp-serverの動的なツール呼び出しを未対応として拒否していたため、エージェントはTUIセッションを通じて他のCodexタスクを検査・管理できなかった。タスクの一覧・読み取り・待機・作成・フォーク・メッセージ送信・リネーム・アーカイブ・復元のためのcodex_tuiツール名前空間を追加する。ツール呼び出しは既存のapp-serverのスレッド操作を通じて処理し、入力と応答には上限を設け、呼び出し完了またはTUI切断時にクリーンアップする。委譲用のツールは、設定・管理されたMCPポリシーを尊重しつつ、明示的な承認プロンプト付きの認証済みローカルMCPサーバー経由でルーティングする。動的ツールに対応していない古いapp-serverに接続した場合は、動的ツールなしでスレッドを開始する形にフォールバックする）

タスクの一覧・読み取り・待機・作成・フォーク・メッセージ送信・リネーム・アーカイブ・復元と、9種類の操作が挙げられている。実装は既存のapp-serverのスレッド操作を土台にしており、認証済みのローカルMCPサーバーを経由し、明示的な承認プロンプトを伴う設計だ。

「@」で選ぶとどうなるか

続く#40315は、この操作群をTUIの入力欄（composer）から「@」で呼び出せるようにする部分を実装している。

• Include matching Codex tasks in the @ mention popup when the active thread supports task tools, prioritizing tasks from the current working directory.
• Submit selected tasks as bounded live thread references so Codex can load their contents with read_thread.
• Preserve task mentions across composer history and thread start, resume, and fork flows.

（アクティブなスレッドがタスクツールに対応している場合、@メンションのポップアップに一致するCodexタスクを含め、現在の作業ディレクトリのタスクを優先的に表示する。選択されたタスクは、Codexがread_threadでその内容を読み込めるよう、範囲を限定したライブなスレッド参照として送信される。タスクメンションは、入力欄の履歴やスレッドの開始・再開・フォークをまたいで保持される）

「現在の作業ディレクトリのタスクを優先」という挙動から、同じプロジェクト内で複数のタスクを並行して走らせている場面を主な想定用途としていると読み取れる。

承認プロンプトが挟まる設計——9ツールの正確な名前と承認モード

#40308の本文には「明示的な承認プロンプト付きの認証済みローカルMCPサーバー経由でルーティングする」とあるが、実際にPR差分（.diff）を読むと、ツールごとの正確な名前と、どの操作に承認プロンプトが出るのかが具体的に書かれていた。

出典: PR #40308差分codex-rs/tui/src/dynamic_tools.rs（2026年8月29日確認）

つまり、他のタスクを新規作成・フォーク・メッセージ送信で操作する3つの操作には明示的に承認プロンプトが設定されている一方、一覧・読み取り・待機の4つはMCPツールとして「読み取り専用（read-only）」の注釈が付けられている。リネームとアーカイブ/復元の2つは、個別の上書き指定がなく、このダイナミックツールサーバー全体の既定値（"approve"）に従う形になっており、promptとapproveという2つの異なるモード名が使い分けられている理由（両者の挙動の違い）までは、今回確認したPR差分の範囲では判別できなかった。

実際に複数タスクを並行して「@」参照を試したわけではない

本記事はCodex 0.150.0のリリースノート本文、実装PR #40308・#40315の本文、そしてPR #40308の差分ファイル（Rustソース）を情報源としている。promptとapproveという2つの承認モード名の正確な意味の違いは、コード上の値としては確認できたが、それぞれが実際にTUI上でユーザーにどう表示されるのか（同じ確認ダイアログなのか、違う扱いなのか）は確認できていない。この記事を書いている自分の手元では、実際にCodexで複数のタスクを同時に走らせ、TUIの入力欄から「@」メンションで別タスクを参照し、read_threadや承認プロンプトの挙動を確認する検証は行っていない。

関連記事: Codex Goal Mode 一般提供開始 / AIエージェントとは / Codexに「中断されたら実行されるフック」が追加

感想・指摘はコメント欄へ。