Claude CodeをiTerm2で使うとGOKが入る不具合は2.1.301で修正

iTerm2でClaude Codeを起動すると、プロンプトに何も打っていないのに「GOK」という3文字が入る症状は、Claude Code 2.1.301で修正されました。まずはclaude updateでアップデートしてください。iTerm2側も3.7.4に上げて直ったという報告があります。原因はKitty graphics protocolの画像対応チェックにiTerm2が非準拠の形で応答し、Claude Code側の正規表現がそれを解釈できずキー入力として扱ってしまうことです。アップデートできない場合の回避策は、シェルで環境変数をexportしてから起動することで、settings.jsonのenvに書いても効きません。Warpで出るリンク関連の不具合はClaude CodeをWarpターミナルで使うと出る不具合にあります。

直し方はClaude Codeのアップデート

GitHub issueの担当者コメント(2026年10月16日)によると、2.1.301で修正されました。影響があったのは古いiTerm2で、3.5.11から3.5.14が挙げられています。#95448は同日にクローズされ、後述の#98973にも同じコメントが付いています。

claude update
claude --version

バージョンが2.1.301以上なら、GOKは出ないはずです。10月14日には、iTerm2を3.5.14から3.7.4に更新して直ったというコメントも付いています。Claude Codeを更新できない環境では、後述の環境変数による回避策が使えます。

起動のたびにプロンプトに「GOK」が残る

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

> GOK█

GitHub issue #95448は2026年9月18日に起票されました。多重化ソフト(tmux / screen)もSSHも挟まないローカルのiTerm2で、どのディレクトリでも起動のたびに再現し、負荷には依存しません。起票時の環境はClaude Code 2.1.275、iTerm2 3.5.11、macOS 26.0(Darwin 25.6.0)です。

9月28日には別のユーザーがコメントで同じ症状を報告しています。環境はClaude Code 2.1.283とiTerm2 3.5.14で、起票時よりiTerm2もClaude Codeも新しい組み合わせでも出ています。

Claude Codeのターミナル設定ページの表は、iTerm2をGhostty・Kitty・WezTermなどと並べ、Shift+Enterで改行できる端末(設定不要)に挙げています。この表は改行キーの話で、画像対応チェックへの応答には触れていません。キー入力の設定が要らないことと、起動時の問い合わせに規格どおり返すことは別の話です。

報告者の環境ではTERM_PROGRAM=iTerm.app、TERM=xterm-256color、COLORTERM=truecolorでした。症状はこの3つの値から端末を判定した結果ではなく、返事の形そのものから起きています。

原因はプローブへの返事がキー入力に回ること

Claude Codeは起動時にターミナルの機能を確かめるため、複数のエスケープシーケンスを送って返事を待ちます。そのひとつが、インライン画像表示に対応しているかを調べるKitty graphics protocolのプローブで、起動から入力欄への混入までは次の流れです。

報告者の説明では、返事を認識できないので問い合わせは未応答のまま残り、返事のバイト列がキー入力の側へ流れ込みます。issueに載っている応答の解析パターンは次のとおりです。

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

issueの報告者が取得した生ログでは、同じ起動中に送られた他の4つの問い合わせにiTerm2は想定どおりの形で返しています。

形が崩れているのは画像対応プローブへの返事だけです。

Kitty graphics protocolの公式仕様は、コマンドに付けたi(またはI)の値を応答にそのまま含めて返すよう定めています。報告者はこれを根拠にiTerm2側が非準拠だとして、iTerm2側にも報告したと書いています。一方で、解釈できなかった返事をキー入力に回さず捨てる設計なら、Claude Code側でも症状は防げたはずだと述べています。

手元の端末が同じ応答をするか確かめる

issueに掲載されているPythonスクリプトを使うと、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

報告者の環境では上の返事が返り、i=が含まれていないことを直接確かめられます。Kittyの仕様に沿った端末ならi=31を含む返事になるはずなので、返事の中身を見れば自分の端末がどちら側かを切り分けられます。

実行は端末アプリのウィンドウで直接行います。ターミナルを持たない環境(Claude Codeに任せたBashツールの実行など)では/dev/ttyを開けず、OSError: [Errno 6] Device not configuredで止まります。

回避策は環境変数をシェルでexportする

issueが挙げている回避策は、画像対応を自動判定させず強制扱いにする環境変数です。

export CLAUDE_CODE_FORCE_TERMINAL_IMAGES=1

毎回打つのは手間なので、zshの場合は次のように起動設定へ書き込みます。

echo 'export CLAUDE_CODE_FORCE_TERMINAL_IMAGES=1' >> ~/.zshrc

新しいウィンドウを開いてからclaudeを起動し直すと、設定が読み込まれます。bashなら書き込み先は~/.bashrcか~/.bash_profileです。

置き場所には落とし穴があります。環境変数ページには、settings.jsonのenvは設定ファイルから直接読まれるので起動方法を問わず有効になる、と書かれており、報告者の説明と食い違っています。

環境変数ページの一覧には、端末の自動判定を上書きする変数が2つあります。CLAUDE_CODE_FORCE_SYNC_OUTPUT(同期出力)とCLAUDE_CODE_FORCE_STRIKETHROUGH(取り消し線の描画)です。CLAUDE_CODE_FORCE_TERMINAL_IMAGESはその中に含まれません。

後者は、TERM_PROGRAMが転送されないSSH越しなど、端末を自動判定できないときに~~text~~を取り消し線として描画させる変数です。起動時の自動判定に頼る機能に、利用者側から値を強制する逃げ道が用意されているわけです。報告者自身も、この回避策は別途ドキュメントに載せる価値があるかもしれないと書いています。

2つの画像対応判定がどちらも外れる

issueの報告者によると、Claude Codeが端末の画像対応を判定する経路は2つあり、iTerm2はどちらでも対応外に分類されます。

プロトコル自体には応答しているのに画像非対応の端末として扱われ続けるのが、このissueの副作用です。報告者は、iTerm2は実際には画像表示に対応しており、プローブへの返事がそれを示していると述べています。応答の解析を直せば、GOKの混入と誤判定は同時に解消するという指摘です。

修正案も2つ出ています。

1. i=が無い返事も許容する。画像プローブは同時に1件しか飛ばさないので、i=なしのOKも同じプローブへの返事として受ければ、問い合わせの取り違えは起きません。
2. 解釈できなかったOSC・DCS・APC形式の返事は、キー入力に回さず破棄する。実装されれば、iTerm2以外の端末で将来同じ種類の不一致が起きても入力欄は汚れません。

報告者が期待する動作は、プローブの返事が消費されるか破棄され、プロンプトの入力バッファに何も届かないことです。#95448は2.1.301の修正でクローズされました。

別の端末・別の症状なら関連issueを見る

プローブの返事が入力欄や画面に漏れる不具合は、issue #95448以外にも起票されています。今回のiTerm2は、返事の正規表現が一致しないことが原因でした。関連として挙げられているissueは、タイミングやエコー設定が原因の別経路です。

#91530の題名は「プローブの返事が入力として読まれる」とあります。新しく作ったtmuxのペインでclaude --resumeを実行すると、起動中にプローブの返事をキー入力として読み、終了コード1で落ちる報告です。tmuxなしの--resumeと、tmux内の素のclaudeは動くため、環境の組み合わせで決まります。

#93004はGhostty 1.3.1・Claude Code 2.1.263で、端末名とDA1の返事が^[P>|ghostty 1.3.1-arch2^[\^[[?62;22;52cのまま画面の上部に出る報告です。報告者は、返事をClaude Codeが消費せず、端末のライン処理がエコーしていると説明しています。

#78693は、Terminal.appからSSHで接続したフルスクリーン表示で、トラックパッドのスクロールやクリックのたびに<65;62;34Mのような文字が入力欄に残る報告です。#78855は、ホストの負荷が高いときにSGRマウス報告が複数回の読み取りに分かれ、<65;59;28M5;59;28Mのように先頭が欠けた断片が入力に入る報告です。macOS上のtmux 3.6aで観察されています。いずれもオープンのままです。入力欄や画面に出る文字列の見た目から、近いissueを探せます。

#95448の報告者が挙げた2つ目の修正(解釈できない返事の破棄)は、#78855・#78693・#91530にも効くと指摘されています。

同じGOKでも再現条件が違う報告がある

2026年10月2日には、別の報告者がissue #98973を起票しました。Claude Code 2.1.285・iTerm2 3.5.12・macOSで、起動のたびに入力欄へ「GOK」が入り、カーソルがその直後に置かれる症状です。#95448と症状は同じですが、報告者が示す再現条件は違います。プロジェクトにCLAUDE.mdとAutoMemのMEMORY.mdがあるディレクトリで起動したときだけ出て、$HOMEから起動すると出ません。報告者は、CLAUDE.mdとMEMORY.mdを読み込んだ直後の内部の通信と出現の時期が重なる、という見立てを書いています。

#98973にも、2.1.301で修正されたという同じコメントが付いてクローズされました。2.1.301以上でも出るなら、起動したディレクトリのCLAUDE.mdの有無を変えて試すと、どちらの報告に近いかが分かります。

iTerm2側の仕様も押さえておくと、#95448の見立てが読みやすくなります。iTerm2には独自のInline Images Protocol(ESC ] 1337 ; File=)があります。公式ドキュメントによると、Kitty graphics protocol(APC G)にも対応しています。画像が表示できる端末なのに、プローブの返事の形だけが合わずに対応外と扱われている、というのが報告者の整理です。

入力欄の文字は送信前に消す

起動のたびに未知の文字列が残る症状でも、入力を全部消してから使い始めれば作業自体はできます。気づかずに送信すると、GOKを含んだメッセージが実行されます。回避策を一度設定しておくと毎回の確認が要らなくなります。消す前に書きかけの内容を残したいなら、Ctrl+Sでのスタッシュで退避できます。

まとめ

2.1.301以上にアップデートすれば解消します。更新できない間の回避はCLAUDE_CODE_FORCE_TERMINAL_IMAGES=1をシェル側でexportして起動することです。症状が別の文字列なら、関連issueの表で近いものを探すと切り分けが早くなります。