プロジェクトの背景：このアダプターは
Claude Code v2.1.88のリークされたソースコードの分析に基づいて作成されました。目的は、CodexにClaude Codeと同様の能力を持たせ、JetBrainsシリーズのIDEで現在選択されているファイル、行番号、コード範囲を認識できるようにすることです。Author:
nealzhi
本ドキュメントでは、唯一の導入経路である HUD + hooks のみを扱います。
本リポジトリからは、古い「ローカルMCPサーバー + グローバルプロンプト」方式を削除しました。その方式は推奨しておらず、提供も終了しています。
以下の2つの条件を満たしている必要があります：
JetBrainsシリーズのIDEを使用していること
例：IntelliJ IDEA、PyCharm、WebStorm、GoLand、Android Studio
IDEに Claude Code 公式 JetBrains プラグイン がインストールされていること
これが連携の前提です。このプラグインがないと、ローカルの ~/.claude/ide/*.lock や対応するローカルインターフェースが存在せず、Codexは現在選択中のファイルやコード範囲を読み取ることができません。
Related MCP server: Claude Code Control MCP
リポジトリのルートディレクトリで以下を実行します：
cd codex-jetbrains-mcp
npm install
brew install tmux説明：
npm install：HUDとhooksの依存関係をインストール
tmux：HUDの依存先
リポジトリのルートディレクトリで以下を実行します：
chmod +x codex-jetbrains-mcp/bin/codex-jetbrains-hud今後 codex を実行する際に自動的にHUDを起動したい場合は、以下の行を ~/.zshrc または ~/.bashrc に追加してください：
alias codex='$(pwd)/codex-jetbrains-mcp/bin/codex-jetbrains-hud'シェルを再読み込みします：
source ~/.zshrcbash を使用している場合は以下を実行します：
source ~/.bashrcmacOS標準のターミナルやWarpターミナルでマウスホイールによるCodexウィンドウのスクロールができない場合は、以下のコマンドを実行して tmux のマウスサポートを有効にできます：
tmux set -g mouse onHUDが起動すると、以下の行が表示されます：
JetBrains PyCharm 已连接 | test_main.py:2140-2147 (8 lines)このスキームの核心は以下の通りです：
codex 起動時にHUDを同時に起動する
HUDがJetBrainsの現在ファイル/行番号を自動的に .codex/jetbrains-selection-state.json に書き込む
UserPromptSubmit hookがメッセージ送信時にこの状態を読み取る
JetBrainsのコンテキストがある場合、「ファイルパス」または「ファイルパス + 行番号」のみを注入する
選択されたテキスト自体は注入せず、Codexが必要に応じてファイルを読み取るようにする
リポジトリのルートディレクトリで以下を実行します：
chmod +x codex-jetbrains-mcp/bin/codex-jetbrains-hud
alias codex='$(pwd)/codex-jetbrains-mcp/bin/codex-jetbrains-hud'以降は通常通り codex を実行してください。
現在、codex-jetbrains-hud はHUDを表示するだけでなく、hookに必要な状態を自動的に同期します。これが唯一の推奨経路であり、個別の同期プロセスは不要であり、提供もしていません。
状態ファイルは以下に書き込まれます：
.codex/jetbrains-selection-state.jsonリポジトリには以下が含まれています：
.codex/config.toml
.codex/hooks/selection-state.mjs
.codex/hooks.json
.codex/hooks/user-prompt-submit-jetbrains-selection.mjs
導入方法は2通りあります：
このリポジトリディレクトリ内で codex を起動する場合
Codexはリポジトリ内の .codex/config.toml と .codex/hooks.json を直接読み取るため、追加のパス指定は不要です。
すでに独自のグローバルな ~/.codex/hooks.json を持っている場合
それを上書きせず、リポジトリ内の UserPromptSubmit 設定をマージしてください。
~/.codex/hooks/ にコピーする場合は、エントリファイルだけでなく .codex/hooks/ ディレクトリ全体をコピーしてください。
.codex/config.toml の役割は、公式が要求するhooks機能のスイッチをオンにすることです：
[features]
codex_hooks = true公式ドキュメントに従い、hooksはデフォルトで無効になっているため、config.toml で有効にするか、起動時に codex --enable codex_hooks を渡す必要があります。また、Codexの設定レイヤーは ~/.codex/config.toml とリポジトリ内の .codex/config.toml を合わせて読み取ります。プロジェクトが信頼済み（trusted）としてマークされていない場合、リポジトリレベルの .codex/config.toml は有効になりません。
リポジトリ付属の設定内容は以下の通りです：
{
"hooks": {
"UserPromptSubmit": [
{
"hooks": [
{
"type": "command",
"command": "node \"$(git rev-parse --show-toplevel)/.codex/hooks/user-prompt-submit-jetbrains-selection.mjs\"",
"statusMessage": "Loading JetBrains selection"
}
]
}
]
}
}このhookは、UserPromptSubmit のたびにローカルの状態ファイルを読み取ります：
ファイルのみが選択されている場合、Codexに「現在のファイル」を注入する
コード範囲が選択されている場合、Codexに「現在のファイル + 行番号」を注入する
JetBrainsのコンテキストがない、または状態が期限切れの場合は何も注入しない
コードテキストは注入せず、位置のガイドのみを行います。
以前のバージョンを使用していた場合は、以下の2つを削除してください：
ローカルMCP設定の削除
codex mcp remove jetbrains-selection独自のグローバルプロンプト内の該当内容の削除
每次用户请求时，先调用 MCP 工具 jetbrains-selection.jetbrains_get_selection 获取 JetBrains 当前选区この手順は必須です。そうしないと、モデルが古い思考プロセスに従って存在しないMCPツールを呼び出そうとする可能性があります。
ファイルのみを選択した場合、以下のような内容が注入されます：
JetBrains 当前选中文件：/path/to/file.ts
这只是文件指引，没有附带文件内容。
如果本轮问题和这个文件相关，请先自行读取该文件；如果无关，请忽略这条上下文。コード行を選択した場合、以下のような内容が注入されます：
JetBrains 当前选中位置：/path/to/file.ts:120-146
这只是位置指引，没有附带代码内容。
如果本轮问题和这个位置相关，请先自行读取对应文件和行号；如果无关，请忽略这条上下文。デフォルトの状態有効期限は 20s です。HUDの実行中、状態は 5s ごとに更新されます。HUDが終了すると、hookはすぐに古い状態の注入を停止します。環境変数 CODEX_JB_HOOK_MAX_AGE_MS を通じてこの時間を調整することも可能です。
旧方式には主に以下の問題がありました：
codex mcp add を別途実行する必要があり、インストールとメンテナンスのコストがかかる
モデルがグローバルプロンプトに依存し、「毎ターン必ず一度MCPを呼び出す」ことを強制されるため、JetBrainsの選択範囲と無関係な質問でも無駄なステップが発生する
選択範囲が関連しているかどうかは本来現在の質問内容によって決まるべきであり、グローバルプロンプトに含めると動作が機械的になりすぎる
ローカルMCPサーバーは中継層に過ぎず、実際にはClaude Code JetBrainsプラグインに接続する必要がある。この層を個別に維持するメリットは低く、複雑さが増す
古い設定のクリーンアップが困難で、移行後に無効なツール名や古いプロンプトが残りやすい
HUD + hooksに変更した後のメリットはより直接的です：
メッセージ送信時にのみローカル状態を読み取るため、毎ターンMCP呼び出しが発生しない
注入内容はファイルパスや行番号のみであり、情報がクリーン。モデルが自分でファイルを読みに行くかどうかを判断できる
状態ファイルはプロジェクトルートごとに分離され、プロジェクトごとに .codex/jetbrains-selection-state.json が書き込まれる
HUDが生存している間はハートビートが更新され、HUDが停止すると古い状態はタイムアウト後に自動的に無効化される
導入経路が単一化され、ユーザーはHUDとhooksのみをメンテナンスすればよく、MCP設定をメンテナンスする必要がない
データリンクは以下の通りです：
Claude Code 公式 JetBrains プラグインがローカル接続情報と選択イベントを公開する
HUDが現在の作業ディレクトリに基づいて正しいJetBrainsプロジェクトウィンドウをマッチングする
HUDが選択範囲の変更を受け取ると、ファイルパス、行番号、ハートビート時間を現在のプロジェクトの .codex/jetbrains-selection-state.json に書き込む
UserPromptSubmit hookがメッセージ送信時にこの状態を読み取る
状態が有効であれば、Codexに「現在のファイル」または「現在のファイル + 行番号」の軽量なプロンプトを注入する
このリンクにはローカルMCPサーバーは存在せず、追加のグローバルプロンプトも不要です。
上記の手順が完了したら：
JetBrains IDEを開く
codex を起動する
HUD経由で起動した場合、HUDが自動的にhook状態を同期する
Claude Code公式プラグインをインストールしたJetBrains IDEに戻り、ファイルまたはコードの一部を選択する
HUDに現在のファイルと行番号が表示されていることを確認する
Codexで通常通り質問する
HUDが更新されない場合、最も確実な方法は以下の通りです：
IDEに戻り、ファイルを再度クリックする
または、選択範囲を再度ドラッグし直す
正常な場合：
ファイルのみを選択すると、Codexはファイルパスのガイドを受け取る
コード範囲を選択すると、Codexはファイルパスと行番号のガイドを受け取る
JetBrainsのコンテキストがない場合、JetBrains関連のプロンプトは一切注入されない
Return the current file path and selected lines forwarded by the Claude JetBrains plugin.
| Name | Required | Description | Default |
|---|---|---|---|
| maxChars | No | ||
| includeText | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully disclose behavioral traits. It fails to indicate whether the operation is read-only, destructive, or requires authentication. Mentioning 'forwarded by the Claude JetBrains plugin' weakly implies a read operation but is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the main purpose. However, it is slightly under-specified for a tool with multiple parameters, but still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (2 parameters, no output schema), the description provides a high-level overview of the return value ('file path and selected lines') but lacks details about the format, structure, or behavior (e.g., what happens if no selection exists). It is minimally adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description does not explain any parameters (maxChars, includeText) or their purpose. The schema provides defaults and constraints, but the description adds no value beyond that, leaving the agent uninformed about how to use the parameters effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool returns the current file path and selected lines from the JetBrains plugin. This verb-resource combination is specific and distinct from sibling tools like jetbrains_list_instances or jetbrains_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor are there any exclusions or prerequisites mentioned. The description only states what it does, not the context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List discovered JetBrains plugin instances and show which one matches the current project.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It mentions listing and matching but does not discuss side effects (likely none, read-only), authorization requirements, or potential limitations. This is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the core functionality with no unnecessary words. It is concise, though could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there are no parameters, no output schema, and no annotations, the description provides minimal context. It lacks details about the output format, the definition of 'matches', and any behavior beyond listing. While acceptable for a simple list tool, it leaves gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero properties, so there are no parameters to describe. Per guidelines, a baseline of 4 is appropriate since the description does not need to add parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'JetBrains plugin instances', and adds the specific behavior of showing which instance matches the current project. This distinctly differentiates it from sibling tools like jetbrains_get_selection or jetbrains_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that the tool is for listing instances and identifying the project-matched one, but it does not explicitly state when to use it over alternatives or when to avoid using it. No usage context or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the upstream MCP tools exposed by the Claude JetBrains plugin connection for debugging and extension work.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates a read operation by 'list', but with no annotations, it does not disclose any additional behavioral traits such as permissions, side effects, or limitations. Basic transparency is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no superfluous words, clearly stating the tool's function and context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose and use-case but does not specify output format (e.g., list of tool names or details). For a simple list tool without output schema, this is adequate but could be more informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters; the empty schema is fully described. The description does not need to add parameter information beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'List the upstream MCP tools' with a clear verb and resource, and distinguishes from siblings like jetbrains_get_selection by specifying 'upstream MCP tools'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'for debugging and extension work' which gives context, but lacks explicit when-to-use or alternatives guidance. No comparison with sibling tools is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Force a fresh scan of lockfiles and reconnect to the matching JetBrains plugin instance.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions 'force a fresh scan' and 'reconnect' but does not explain side effects (e.g., whether current state is disrupted, auth requirements) or what happens to existing connections.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no wasted words. Every part delivers essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is minimal but covers the core action. However, it lacks details on side effects, prerequisites, or postconditions, leaving some gaps for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so baseline is 4. The description adds meaning by explaining the tool's actions (scan lockfiles, reconnect) beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it forces a fresh scan of lockfiles and reconnects to the matching JetBrains plugin instance. This specific verb-resource pair distinguishes it from siblings like get_selection or list_instances.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is given. The description implies it's for refreshing a stale connection or lockfiles, but alternatives are not mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show connection status for the Claude JetBrains plugin adapter.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only says 'Show connection status'. Does not disclose whether it performs a live check or returns cached state, or any side effects. Minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no fluff, perfectly sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero complexity, no parameters, no output schema, and no annotations, the description fully covers what the tool does.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters, so the description naturally adds no param info. According to calibration rules, 0 params = baseline 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'Show' and resource 'connection status for the Claude JetBrains plugin adapter'. Distinguishes from sibling tools like jetbrains_refresh_connection which implies a different action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when or when-not to use, but the simplicity of a zero-parameter status check makes usage obvious. No alternatives mentioned, but siblings indicate other connection-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0jetbrains_get_selectionjetbrains_list_instancesjetbrains_list_upstream_toolsjetbrains_refresh_connectionjetbrains_statusScored across 5 tools
Each tool has a clearly distinct purpose: getting selection, listing instances, listing upstream tools, refreshing connection, and showing status. No two tools could be confused.
All tools follow a consistent 'jetbrains_' prefix with verb_noun pattern (get_selection, list_instances, list_upstream_tools, refresh_connection, status). No mixing of conventions.
With 5 tools, the set is well-scoped for a connection adapter that manages plugin instances and retrieves selections. Each tool earns its place without unnecessary bloat.
The tool surface covers the core operations: get current selection, list/manage instances, refresh connection, and check status. Minor gaps like setting selection or executing actions are absent, but the stated purpose is well-covered.
Use your Mac, Windows or Linux computer from ChatGPT, Claude or Codex: files, commands, documents.
Share context and questions between Claude instances — VS Code, claude.ai web, and mobile.
Persistent memory for Claude Code and Cursor. Stop re-explaining your project every session.
Bring meeting decisions, tasks and user stories into your AI editor (Claude, Cursor, Copilot).