Claude CodeをiTerm2で使うとGOKが入力される不具合の対処法

iTerm2でClaude Codeを起動すると、プロンプトに何も打っていないのに「GOK」という3文字が入力されている症状が報告されています。原因はKitty graphics protocolの画像対応チェックにiTerm2が非準拠の形で応答し、Claude Code側の正規表現がそれを解釈できずキー入力として扱ってしまうことです。修正版が出るまでは、環境変数で回避します。

Claude CodeをiTerm2で使うと何が起きるか

新しいセッションを開くたびに、プロンプト入力欄に次のように文字が残ります。

> GOK█

GitHub issue #95448によると、多重化ソフト(tmux / screen)もSSHも挟まないローカルのiTerm2で、セッションを開くたびに再現します。報告時点の環境はClaude Code 2.1.275、iTerm2 3.5.11、macOS 26.0(Darwin 25.6.0)です。負荷や実行内容には依存しません。

なぜGOKが入力されるのか

Claude Codeは起動時にターミナルの機能を確認するため、複数のエスケープシーケンスを送って応答を見ています。そのひとつが、インライン画像表示に対応しているかを調べるKitty graphics protocolのプローブです。

Claude Codeは次のクエリを送ります。

i=31,s=1,v=1,a=q,t=d,f=24

これに対しiTerm2は、i=キーを含めずにOKとだけ返します(\x1b_GOK\x1b\\)。ところがClaude Code側の応答解析には次の正規表現が使われており、i=<数字>;という形が無いと一致しません。

/\x1b_G(?:[^;]*,)?i=(\d+)[^;]*;(.*?)\x1b\\/s

一致しないため、この応答は「Kitty graphics protocolの返信」としては処理されず、キューに残ったままキー入力デコーダーに渡ります。エスケープシーケンスの導入部と終端部が取り除かれた結果、中身のGOKだけがそのままプロンプトに打ち込まれます。

同じタイミングで送られる他の4つのエスケープシーケンス問い合わせには、iTerm2は仕様どおりの形式で応答しています。画像対応プローブの応答だけがこの形式から外れており、iTerm2側の応答がここだけ孤立して非準拠になっていることが、issueの報告者が取得した生ログから分かります。

Kitty graphics protocolの公式仕様では、画像作成コマンドに送ったi(またはI)の値を応答にそのまま含めて返すことが定義されています。issueの報告者はこの点を根拠に「応答にi=を含めていないiTerm2側が仕様に準拠していない」と指摘し、iTerm2側にも同じ内容を報告済みだとしています。ただしClaude Code側も、解釈できなかったエスケープシーケンスをキー入力として扱わずに捨てる設計にしておけば、この症状自体は起きなかったはずだと述べています。

症状を自分で再現・確認する方法

「本当にKitty graphics protocolのプローブが原因か」を手元で確かめたい場合は、issueに掲載されているPythonスクリプトで、iTerm2が返す生の応答を直接読み取れます。Claude Codeを介さず/dev/ttyを生モードにして同じクエリを送り、返ってきたバイト列をそのまま表示するだけの短いスクリプトです。

python3 - <<'EOF'
import os, termios, tty, select
fd = os.open("/dev/tty", os.O_RDWR); saved = termios.tcgetattr(fd)
try:
    tty.setraw(fd)
    os.write(fd, b"\x1b_Gi=31,s=1,v=1,a=q,t=d,f=24;AAAA\x1b\\")
    print(os.read(fd, 256) if select.select([fd], [], [], 1)[0] else b"(no reply)")
finally:
    termios.tcsetattr(fd, termios.TCSADRAIN, saved); os.close(fd)
EOF

iTerm2上でこれを実行するとb'\x1b_GOK\x1b\\'が返り、i=キーが含まれていないことが直接確認できます。Kittyでは仕様どおりi=31を含む応答が返るため、同じスクリプトで自分の端末がどちら側に当たるかを切り分けられます(ghosttyはXTVERSIONの端末名判定で対応扱いになる端末です)。

どの端末が影響を受けるか

Claude Codeのインライン画像表示は、端末の対応状況によって挙動が変わります。issueの記述から分かる範囲は次のとおりです。

iTerm2は「誤判定」と「入力漏れ」の両方に該当しており、これが今回のissueの核心です。

対処法 — 環境変数でプローブを止める

当面の回避策は、画像プローブそのものを送らせないことです。

export CLAUDE_CODE_FORCE_TERMINAL_IMAGES=1

この環境変数をシェルの起動設定(.zshrcや.bashrcなど)に書いてClaude Code起動前に読み込ませると、Kitty graphics protocolのプローブが送られなくなり、GOKが入力される症状も止まります。CLAUDE_CODE_FORCE_TERMINAL_IMAGESは、issueの報告者が回避策として挙げている環境変数です。

副作用 — iTerm2が画像非対応と誤判定される

このプローブの失敗にはもうひとつ影響があります。Claude Codeがインライン画像表示に対応しているかを判定するもう一つの手段は、XTVERSIONで返ってくる端末名をkitty・ghostty(またはkittyのバージョン0.28以降)と突き合わせる方法です。iTerm2はiTerm2 3.5.11という名前を返すため、この判定でも対応外と分類されます。

つまり2つの判定経路がどちらも「iTerm2は画像非対応」という結果になり、実際にはプロトコル自体は応答しているにもかかわらず、Claude Codeからは画像表示に対応していない端末として扱われ続けます。issueの報告者は、レスポンスのパース処理を直せばこの誤判定も同時に解消すると指摘しています。

修正案として挙げられている2つの方向性

issueの報告者は、Claude Code側で直せる修正案を2つ提示しています。

1. i=が無い応答を許容する案。画像プローブは同時に1件しか飛ばさないため、i=を省略した応答も同じプローブへの返事として扱えば、複数の問い合わせが混同される心配はありません。
2. 解釈できなかった応答をキー入力に回さない案。プローブとして送ったエスケープシーケンスの解析に失敗した場合、その内容を破棄してプロンプトには渡さないようにする方法です。実装されれば、iTerm2以外の端末で将来同種の不一致が起きても症状自体が発生しなくなります。

報告者は2番目の修正が入れば、同じ失敗パターンを持つ関連issueの#78855・#78693・#91530についても、同様に防げると指摘しています。

他の類似issueとの関係

このissueでは、同じ「プローブへの応答がプロンプトや画面に漏れる」失敗パターンとして#93004・#91530・#78855・#78693が関連issueに挙げられています。これらはタイミングやエコー設定が原因で起きる別経路の症状で、今回のiTerm2のケースは応答の正規表現が一致しないことが原因という点で異なります。根本原因は個別でも、症状としては同じカテゴリーに属します。

起動のたびに未知の文字列がプロンプトに残る症状を見つけたときは、まず入力を全部消してから使い始めれば作業自体への支障はありません。ただし気づかずに送信してしまうと、意図しない文字列を含んだメッセージをそのまま実行させてしまう恐れがあるため、症状に気づいた時点で環境変数による回避を設定しておくのが安全です。

まとめ

iTerm2でClaude Codeのプロンプトに「GOK」が勝手に入力されるのは、Kitty graphics protocolの画像対応チェックにiTerm2がi=を省いた形で応答し、Claude Code側の正規表現がそれを解釈できずキー入力として扱ってしまうためです。原因はiTerm2とClaude Codeの双方に指摘の余地がありますが、修正が入るまではCLAUDE_CODE_FORCE_TERMINAL_IMAGES=1をシェル側でexportして起動する方法が確実です。settings.jsonのenvでは効かない点に注意してください。

iTerm2でのプロンプト操作に不便を感じている場合は、Ctrl+Sでプロンプト入力をスタッシュ・復元する方法や、絵文字ショートコードを入力する方法もあわせて確認すると、入力まわりのトラブルシューティングがしやすくなります。ほかの環境固有の不具合としては、Windowsでクロスセッションメッセージが応答しなくなる不具合も同様に端末環境に依存する報告です。

この種の不具合は、Claude Code側とターミナルソフト側のどちらか一方だけを見ていては気づきにくいという特徴があります。今回のケースでは、Kitty graphics protocolという共通の仕様に対して、送信側(Claude Code)の解析処理と受信側(iTerm2)の応答実装の両方に見直す余地があり、報告者自身もiTerm2の開発元へ同じ内容を伝えたと述べています。同様に「起動直後だけ妙な文字が入る」「特定のターミナルでだけ発生する」といった症状に遭遇した場合は、原因をアプリ側だけに絞らず、使っているターミナルソフトのバージョンやプロトコル対応状況も合わせて確認すると切り分けが早くなります。