Claude CodeでGhosttyのDockアイコンが増える原因と確認方法

GhosttyでClaude Codeを何本も動かしていると、macOSのDockに同じGhosttyのアイコンが増えていく。対応するウィンドウはない。この症状がGitHubのissue #99140に報告されています。原因はGhosttyの不具合ではなく、Claudeのプロセスが「Ghosttyという名前のフォアグラウンドアプリ」としてmacOSに登録されることです。報告のコメントには、組み込みのcomputer-useツールが引き金になった例があります。issueはopenのままで、修正は出ていません。

Dockに増えるGhosttyアイコンの正体

#99140の報告者は、並行してターミナルのエージェントを動かすとDockにGhosttyの重複アイコンが溜まる、と書いています。調べると、実際のGhosttyのプロセスは1つだけでした。別のClaude Codeの実行ファイルが、Launch Services(macOSがアプリの起動状態を管理する仕組み)上で2つ目の「Ghostty」として登録されていたのです。

lsappinfo listでそのプロセスを抜き出すと、次の項目が並んでいました(個人のパスは報告側で伏せ字になっています)。

name: Ghostty
bundleID="com.mitchellh.ghostty"
bundle path="/Applications/Ghostty.app"
executable path="~/.local/share/tcc-stable/<hash>/claude"
type="Foreground"
originalExecutablePath="/Applications/Ghostty.app/Contents/MacOS/ghostty"
originalPid=52469

名前とバンドルIDはGhosttyのもので、実行ファイルだけがclaudeです。type="Foreground"は、DockにアイコンをもつふつうのGUIアプリという分類です。ウィンドウを持つか、フォーカスがあるか、作業中かとは関係がありません。

引き金はcomputer-useだという別の報告

標準のインストール(~/.local/bin/claude)で、Claude Code 2.1.289を使っている別の利用者が、同じissueにコメントを付けています。マシンで動いていた7つのclaudeプロセスのうち、2つがGhosttyとして登録され、残り5つは登録されていませんでした。

登録時刻のlsappinfoのチェックイン時刻は、セッションの記録にある最初のmcp__computer-use__request_access呼び出しと同じ秒でした。それ以前のプロセスは未登録だった、というのが根拠です。コメントの筆者は、computer-useのネイティブ部品が、AppKitのアプリを作る前にアクティベーションポリシーを.accessoryにするか、親の識別を引き継がないようにすればよい、という方向を提案しています。

computer-useは、CLIでは次の条件を満たすときに使える機能です。

• macOS専用で、ProまたはMaxプランが必要(TeamとEnterpriseでは使えない)
• 対話セッションのみで、-pを付けた非対話モードでは使えない
• 組み込みのMCPサーバーcomputer-useとして用意され、既定では無効
• /mcpで有効にする。設定はプロジェクト単位で保存される

つまり、computer-useを有効にしていないプロジェクトのセッションは、この引き金には当たらないはずです。ただしこれは、コメント1件の観察からの推論です。issue全体では、引き金がcomputer-useだけだとは確定していません。報告者の側には、どの操作が直前にあったかは分からない、という記述があります。

有効にしたかどうかは、/mcpの一覧でcomputer-useの状態を見るのが早い方法です。有効にしたサーバーの記録がプロジェクトごとに~/.claude.jsonのenabledMcpServersに入る仕組みは、MCPのトークン消費を減らす記事で触れています。

同じ現象がターミナルから起きる仕組み

#99140の報告者は、Claudeを使わない最小の再現を載せています。GUIアプリが子プロセスとして別のCLI実行ファイルを起動し、その子がNSApplication.sharedを作ってfinishLaunching()を呼ぶと、Launch Servicesは子を「親GUIアプリのフォアグラウンドアプリ」として登録しました。

環境変数__CFBundleIdentifierを子に引き継いだ場合と、取り除いた場合の2通りで試しています。

環境変数を消しても防げませんでした。親のGUIアプリの文脈から起動したときだけ起き、その文脈の外で起動した別のプローブは、バックグラウンド専用として登録されたと書かれています。

この実験は、macOSの仕組みを切り出したものです。Claudeのどの処理が原因かまでは示していません。報告者も、Claudeのネイティブ部品がAppKitを初期化している、または通常のフォアグラウンドアプリへ昇格させているのかをメンテナーに調べてほしい、という依頼の形で書いています。

別のコメントには、Ghosttyのシェルから起動したosascriptも、同じようにGhosttyとして登録された、という観察があります。親のターミナルのGUIアプリがあれば、子のプロセスが同じ型の登録を受けることがあるようです。

TERM_PROGRAMとは別の話か

よく一緒に語られるのが、環境変数TERM_PROGRAMの判定です。Claude Codeはターミナルの名前を見て動作を変える部分があり、#98832では未知の値で起動が約3秒遅くなっています。

#98832の報告では、Ghosttyの上で動くマルチプレクサHerdr 0.9.3がTERM_PROGRAM=herdrを設定しています。この値のままだと最初の画面が出るまでが約3秒かかり、TERM_PROGRAM=ghostty claudeと変えただけでほぼ即座に表示されました。Herdrは0.9.2から、外側のターミナルの識別を引き継がず、herdrを名乗る仕様になっています。

Dockのアイコンの件とは、症状も原因の層も別です。

#99140の再現では__CFBundleIdentifierを取り除いても結果が変わらず、TERM_PROGRAMは議論に出てきません。Dockの重複をTERM_PROGRAMの設定で直そうとしても、報告の範囲では根拠がありません。

副作用として起きるGhosttyのAppleScriptの失敗

コメントは、重複アイコンの見た目だけでなく、もう1つ影響を挙げています。claudeがGhosttyとして登録されていると、tell application "Ghostty"の命令がclaudeのプロセスに届いて失敗する、というものです。

Ghostty got an error: Can't continue new window. (-1708)
Ghostty got an error: every window doesn't understand the "count" message. (-1708)

tell application "/Applications/Ghostty.app"とパスで指定しても同じでした。System Eventsでバンドルが同じプロセスを数えると、ghostty, claude, claude, osascriptと並んだ、と報告されています。

スクリプトだけを通す回避策として、JXA(JavaScript for Automation)でパスを指定する書き方が紹介されています。

osascript -l JavaScript -e \
  'Application("/Applications/Ghostty.app").newWindow({withConfiguration:{initialInput:"echo hi\n"}})'

これはAppleScriptの呼び出しを実際のGhosttyに届けるための手段で、Dockのアイコンを消す方法ではありません。

手元で状況を確かめる手順

自分のMacで同じ状態になっているかは、lsappinfoで見分けられます。出力の形はmacOSのバージョンで変わるかもしれないので、見るのは名前・実行ファイルのパス・typeの3項目です。

lsappinfo list | grep -B2 -A8 'bundleID="com.mitchellh.ghostty"'
ps -axo pid,command | grep -E '[g]hostty|[c]laude'

どちらの出力も、grepの範囲で足りない行が出るかもしれません。足りなければ-Aの行数を増やしてください。

いまできる対処と、効かなかった対処

issueに書かれた範囲で、試された方法と結果を分けると次のとおりです。

setinfoは、成功コードが返っても分類は変わりませんでした。この2つの試験は、実験用のアプリ側で行われたものです。実際のClaudeやGhosttyのプロセスには当てていません。

killall Dockについて、報告者は後のコメントで、1回の再起動のあとは重複アイコンが再び現れていない、と書いています。恒久的に直った証拠ではないと断ったうえで、再起動を重ねる必要もない、という観察です。

もう1つ、computer-useを使う予定のないプロジェクトでは、computer-useサーバーを有効にしないという選択肢があります。ただし、これで重複が出なくなるかを試した報告はありません。同じissueに、7つのうち2つだけが登録されていたというコメントがあるように、すべてのセッションに起きるわけでもないようです。

同じ型の別症状として、#91591があります。こちらはデスクトップアプリ(Cowork)が起動するバックグラウンドのClaude Codeセッションが、LSBackgroundOnlyをtrueにしているのに、セッションごとにロケットのアイコンをDockに出す、という報告です。#99140は、ターミナルのCLIがターミナルのアプリの識別で登録される点が違います。

修正を待つあいだの運用

#99140は、メンテナーによる原因の特定も修正バージョンも出ていません。コメント2件も利用者のものです。確定していないのは、どの操作が登録を起こすのか、標準のインストールで毎回起きるのか、の2点です。

Ghosttyの設定やキー入力の症状は、別の記事にまとめています。Optionキー・tmux・Ctrl+Vなどで困っているなら、GhosttyでClaude Codeを使うときの設定と既知の症状から見ると切り分けが早くなります。MacへのインストールそのものはClaude CodeのMacインストールに、全体像はClaude Codeの完全ガイドにあります。

Dockに増えたアイコンは、実際のウィンドウを閉じても消えないことがあります。放置するかkillall DockでDockを再起動するかは、実行中のターミナルやエージェントが影響を受けないことを、psで確認してからにするのが安全です。AppleScriptでGhosttyを操作する自動化を組んでいる場合は、JXAでパスを指定する書き方に寄せるほうが、claudeが混ざった状態でも壊れにくくなります。