Projekthintergrund: Dieser Anpassungsansatz basiert auf der Analyse des geleakten Quellcodes von
Claude Code v2.1.88. Ziel ist es,Codexmit ähnlichen Fähigkeiten wieClaude Codeauszustatten, sodass es die aktuell in JetBrains-IDEs ausgewählten Dateien, Zeilennummern und Codebereiche wahrnehmen kann.Autor:
nealzhi
Dieses Dokument beschreibt nur noch einen Integrationspfad: HUD + Hooks.
Dieses Repository hat die alte Lösung „lokaler MCP-Server + globale Prompts“ entfernt; diese Methode wird nicht mehr empfohlen und nicht mehr bereitgestellt.
Erfüllen Sie zunächst die folgenden zwei Bedingungen:
Sie verwenden eine JetBrains-IDE
Zum Beispiel: IntelliJ IDEA, PyCharm, WebStorm, GoLand, Android Studio
In Ihrer IDE ist das offizielle Claude Code JetBrains-Plugin installiert
Dies ist die Voraussetzung für die Verknüpfung. Ohne dieses Plugin gibt es keine lokalen ~/.claude/ide/*.lock-Dateien und die entsprechenden lokalen Schnittstellen, sodass Codex die aktuell ausgewählte Datei und den Codebereich nicht lesen kann.
Related MCP server: Claude Code Control MCP
Führen Sie im Stammverzeichnis des Repositorys aus:
cd codex-jetbrains-mcp
npm install
brew install tmuxErklärung:
npm install: Installiert HUD- und Hook-Abhängigkeiten
tmux: HUD-Abhängigkeit
Führen Sie im Stammverzeichnis des Repositorys aus:
chmod +x codex-jetbrains-mcp/bin/codex-jetbrains-hudWenn Sie möchten, dass codex zukünftig direkt mit HUD gestartet wird, fügen Sie die folgende Zeile zu Ihrer ~/.zshrc oder ~/.bashrc hinzu:
alias codex='$(pwd)/codex-jetbrains-mcp/bin/codex-jetbrains-hud'Shell neu laden:
source ~/.zshrcWenn Sie bash verwenden, führen Sie aus:
source ~/.bashrcWenn Sie im macOS-Terminal oder Warp-Terminal feststellen, dass das Mausrad das Codex-Fenster nicht scrollen kann, können Sie den folgenden Befehl ausführen, um die tmux-Mausunterstützung zu aktivieren:
tmux set -g mouse onNach dem Start des HUD wird eine Zeile angezeigt:
JetBrains PyCharm 已连接 | test_main.py:2140-2147 (8 lines)Der Kern dieses Ansatzes ist:
Beim Start von codex wird gleichzeitig das HUD gestartet
Das HUD schreibt automatisch die aktuelle JetBrains-Datei/Zeilennummer in .codex/jetbrains-selection-state.json
Der UserPromptSubmit-Hook liest diesen Status, wenn Sie eine Nachricht senden
Wenn ein JetBrains-Kontext vorhanden ist, werden nur der „Dateipfad“ oder „Dateipfad + Zeilennummer“ injiziert
Der ausgewählte Text wird nicht injiziert, damit Codex die Datei bei Bedarf selbst lesen kann
Führen Sie im Stammverzeichnis des Repositorys aus:
chmod +x codex-jetbrains-mcp/bin/codex-jetbrains-hud
alias codex='$(pwd)/codex-jetbrains-mcp/bin/codex-jetbrains-hud'Danach können Sie codex wie gewohnt ausführen.
Jetzt synchronisiert codex-jetbrains-hud neben der Anzeige des HUD auch automatisch den für Hooks benötigten Status. Dies ist der einzig empfohlene Pfad; ein separater Synchronisationsprozess ist nicht erforderlich und wird nicht mehr bereitgestellt.
Die Statusdatei wird geschrieben nach:
.codex/jetbrains-selection-state.jsonDas Repository enthält bereits:
.codex/config.toml
.codex/hooks/selection-state.mjs
.codex/hooks.json
.codex/hooks/user-prompt-submit-jetbrains-selection.mjs
Es gibt zwei Möglichkeiten der Integration:
Wenn Sie codex in diesem Repository-Verzeichnis starten
Codex liest direkt die .codex/config.toml und .codex/hooks.json des Repositorys; Sie müssen keine zusätzlichen Pfade angeben.
Wenn Sie bereits eine eigene globale ~/.codex/hooks.json haben
Überschreiben Sie diese nicht, sondern fügen Sie die UserPromptSubmit-Konfiguration aus dem Repository hinzu.
Wenn Sie diese nach ~/.codex/hooks/ kopieren möchten, kopieren Sie das gesamte Verzeichnis .codex/hooks/ und nicht nur die Einstiegsdatei.
Die .codex/config.toml dient dazu, die offiziell erforderliche Hook-Funktion zu aktivieren:
[features]
codex_hooks = trueLaut offizieller Dokumentation sind Hooks standardmäßig deaktiviert und müssen in der config.toml aktiviert werden oder beim Start mit codex --enable codex_hooks übergeben werden. Außerdem liest die Konfigurationsschicht von Codex sowohl ~/.codex/config.toml als auch die .codex/config.toml im Repository; wenn das Projekt nicht als „trusted“ markiert ist, wird die .codex/config.toml auf Repository-Ebene nicht wirksam.
Der Inhalt der mitgelieferten Konfiguration ist:
{
"hooks": {
"UserPromptSubmit": [
{
"hooks": [
{
"type": "command",
"command": "node \"$(git rev-parse --show-toplevel)/.codex/hooks/user-prompt-submit-jetbrains-selection.mjs\"",
"statusMessage": "Loading JetBrains selection"
}
]
}
]
}
}Dieser Hook liest bei jedem UserPromptSubmit die lokale Statusdatei:
Wenn nur eine Datei ausgewählt ist, wird Codex mitgeteilt, „welche Datei aktuell ist“
Wenn ein Codebereich ausgewählt ist, wird Codex „aktuelle Datei + Zeilennummer“ mitgeteilt
Wenn kein JetBrains-Kontext vorhanden ist oder der Status abgelaufen ist, wird nichts injiziert
Es wird kein Codetext injiziert, nur ein Positionsverweis.
Wenn Sie zuvor die alte Lösung verwendet haben, löschen Sie bitte die folgenden zwei Dinge:
Lokale MCP-Konfiguration löschen
codex mcp remove jetbrains-selectionLöschen Sie solche Inhalte aus Ihren eigenen globalen Prompts
每次用户请求时，先调用 MCP 工具 jetbrains-selection.jetbrains_get_selection 获取 JetBrains 当前选区Dieser Schritt ist zwingend erforderlich, da das Modell sonst möglicherweise weiterhin versucht, ein nicht mehr existierendes MCP-Tool aufzurufen.
Wenn nur eine Datei ausgewählt ist, wird etwa Folgendes injiziert:
JetBrains 当前选中文件：/path/to/file.ts
这只是文件指引，没有附带文件内容。
如果本轮问题和这个文件相关，请先自行读取该文件；如果无关，请忽略这条上下文。Wenn Code-Zeilennummern ausgewählt sind, wird etwa Folgendes injiziert:
JetBrains 当前选中位置：/path/to/file.ts:120-146
这只是位置指引，没有附带代码内容。
如果本轮问题和这个位置相关，请先自行读取对应文件和行号；如果无关，请忽略这条上下文。Die Standardgültigkeitsdauer des Status beträgt 20s. Während das HUD läuft, wird der Status alle 5s aktualisiert; wenn das HUD beendet wird, hört der Hook schnell auf, den alten Status zu injizieren. Sie können diese Zeit auch über die Umgebungsvariable CODEX_JB_HOOK_MAX_AGE_MS anpassen.
Die Probleme der alten Lösung waren hauptsächlich:
Erforderte die zusätzliche Ausführung von codex mcp add, was den Installations- und Wartungsaufwand erhöhte
Das Modell verließ sich oft auf globale Prompts, um „in jeder Runde zuerst ein MCP aufzurufen“, selbst wenn die Frage nichts mit der JetBrains-Auswahl zu tun hatte
Ob eine Auswahl relevant ist, sollte von der aktuellen Frage abhängen; die Platzierung in globalen Prompts machte das Verhalten zu mechanisch
Der lokale MCP-Server war nur eine Zwischenschicht, die eigentlich mit dem Claude Code JetBrains-Plugin verbunden werden musste; diese Schicht separat beizubehalten, bot wenig Nutzen bei höherer Komplexität
Alte Konfigurationen waren schwer vollständig zu bereinigen, was nach der Migration leicht zu ungültigen Tool-Namen oder alten Prompts führte
Nach der Umstellung auf HUD + Hooks sind die Vorteile direkter:
Der lokale Status wird nur beim Senden einer Nachricht gelesen, kein zusätzlicher MCP-Aufruf pro Runde
Der injizierte Inhalt enthält nur Dateipfade oder Zeilennummern, die Informationsmenge ist sauberer, und das Modell entscheidet selbst, ob es die Datei lesen muss
Statusdateien sind nach Projektstammverzeichnis isoliert, jedes Projekt schreibt seine eigene .codex/jetbrains-selection-state.json
Das HUD aktualisiert den Heartbeat kontinuierlich, solange es aktiv ist; nach dem Stoppen des HUD läuft der alte Status nach Ablauf der Zeit automatisch ab
Der Integrationspfad ist einheitlicher, Benutzer müssen nur HUD und Hooks warten, keine MCP-Konfiguration mehr
Die Datenkette sieht so aus:
Das offizielle Claude Code JetBrains-Plugin macht lokale Verbindungsinformationen und Auswahlereignisse verfügbar
Das HUD gleicht das richtige JetBrains-Projektfenster basierend auf dem aktuellen Arbeitsverzeichnis ab
Nachdem das HUD eine Auswahländerung erhalten hat, schreibt es Dateipfad, Zeilennummer und Heartbeat-Zeit in die .codex/jetbrains-selection-state.json des aktuellen Projekts
Der UserPromptSubmit-Hook liest diesen Status, wenn Sie eine Nachricht senden
Wenn der Status gültig ist, wird ein leichter Hinweis auf „aktuelle Datei“ oder „aktuelle Datei + Zeilennummer“ in Codex injiziert
In dieser Kette gibt es keinen lokalen MCP-Server und keine zusätzlichen globalen Prompts erforderlich.
Nach Abschluss der oben genannten Schritte:
Öffnen Sie die JetBrains-IDE
Starten Sie codex
Wenn Sie das HUD zum Starten verwendet haben, synchronisiert das HUD den Hook-Status automatisch
Kehren Sie zur JetBrains-IDE zurück, in der das offizielle Claude Code-Plugin installiert ist, und wählen Sie eine Datei oder einen Codeabschnitt aus
Bestätigen Sie, dass das HUD die aktuelle Datei und Zeilennummer anzeigt
Stellen Sie in Codex eine normale Frage
Wenn das HUD nicht aktualisiert wird, ist das sicherste Vorgehen:
Zurück in die IDE gehen und die Datei erneut anklicken
Oder die Auswahl erneut ziehen
Unter normalen Umständen:
Wenn nur eine Datei ausgewählt ist, erhält Codex einen Dateipfad-Hinweis
Wenn ein Codebereich ausgewählt ist, erhält Codex einen Dateipfad- und Zeilennummern-Hinweis
Wenn kein JetBrains-Kontext vorhanden ist, werden keine JetBrains-Hinweise injiziert
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).