Claude Code VSCode拡張のAlt+K(@メンション挿入)でフォーカスが奪われる・違う会話に切り替わる問題を追った
VSCode拡張の@メンション挿入ショートカット(Option+K/Alt+K)は、2026年に入ってからも「ショートカットが反応しない」「フォーカスが奪われる」「違う会話タブに切り替わる」という報告が繰り返されている。GitHub Issueの実例とstale bot誤クローズ問題まで、現時点で分かっていることを整理した。
エンジニアのゆとです。
VSCode拡張でコードを選択してOption+K(Mac)/Alt+K(Windows/Linux)を押すと、選択範囲を@file.ts#5-10の形式でプロンプトに挿入してくれる——公式ドキュメントにも載っている定番ショートカットだ。ただこの機能、2026年に入ってからも「そもそも反応しない」「反応はするけど関係ない会話タブに切り替わってしまう」という報告がGitHub Issueで繰り返し上がっている。しかも直近の報告の一部は、修正されたからではなく「一定期間放置された」という理由でbotに自動クローズされていた。この記事では、報告されている症状を時系列で整理し、現時点(Claude Code v2.1.260、2026年9月3日リリース)で何が分かっていて何が分かっていないかをまとめる。
結論 — 症状別の現状早見表
| 症状 | 発生時期 | 現状 |
|---|---|---|
| Alt+K / Option+Kを押しても何も起きない | v2.0.10、v2.1.6〜2.1.7で繰り返し発生 | 個別の回帰は都度修正されている模様。今使っているバージョンで発生したら最新版へのアップデートをまず試す |
| Alt+Kを押すと挿入は成功するが、フォーカスが今見ている会話ではなく別の(隠れた)会話タブに移る | 2026年7月から報告が継続 | 未解決。Issueはstale bot(一定期間コメントがないと自動クローズする仕組み)に2回クローズされているが、修正が入った形跡はない |
| Claudeパネルを別ウィンドウに切り離すと、Alt+K/Ctrl+Escがどちらの入力欄にもフォーカスしない | 2026年7月17日報告 | オープンのまま(2026年9月時点) |
マルチルートワークスペースで@ファイルピッカーが最初のフォルダしか検索しない | 2026年8月19日報告 | オープンのまま(2026年9月時点) |
まずは自分の症状がどれに近いか、ここで確認してから該当する見出しに進んでほしい。
前提 — Alt+Kは「挿入」と「フォーカス移動」の2つを同時にやろうとする機能
公式ドキュメントのショートカット一覧では、Insert @-Mention Referenceは「エディタにフォーカスがある状態が前提」の操作として説明されている。つまりAlt+Kを押した瞬間、拡張機能は裏側で2つのことを同時にやっている。
- 選択中のファイル・行範囲を
@file#L1-L2という文字列に変換してプロンプトへ挿入する - 挿入先のClaudeパネル(webview)を表示し、そこにフォーカスを移す
このうち1だけが目的なら大きな問題は起きにくいが、2の「どのパネルにフォーカスを移すか」の判定ロジックが、会話タブを複数開いている環境やウィンドウを分割している環境でうまく機能していない、というのがこの記事で扱う不具合の共通点になる。
症状1｜ショートカット自体が反応しない(過去の回帰)
もっとも基本的な症状で、2025年10月から2026年1月にかけて複数回報告されている。
v2.0.9→v2.0.10で発生(Issue #9142)
2025年10月8日に報告されたIssueでは、Ctrl+Alt+Kがv2.0.9では動くのにv2.0.10で動かなくなったと報告されている。VSCode拡張のUI上のボタンからは実行できるが、ショートカットキーだけ反応しないという内容だった。コメント欄では複数のユーザーが「v2.0.14でも同じ」と追随しており、単発の環境依存バグではなかったことがうかがえる。
v2.1.5→v2.1.6で再発(Issue #18083、#18145)
2026年1月14日、今度はv2.1.6へのアップデートを境に同じ症状が再発した。Windows版の報告(#18083)では、ユーザーがVSCodeのkeybindings.jsonを調べたところ次の状態になっていたという。
alt+k(claude-vscode.insertAtMention用)のバインドが無効化(-プレフィックス)されているctrl+alt+k(claude-code.insertAtMentioned用)に有効・無効の重複エントリが存在する- VSCode本体の
keybindings.editor.recordSearchKeysがalt+kを横取りしている
報告者は「コマンドパレットからも実行できない」「2.1.5では問題なかった」と明記しており、拡張機能側のリグレッションであることは間違いない。Mac版の報告(#18145)でも同様に、コマンドIDがclaude-vscode.insertAtMentionとclaude-code.insertAtMentionedで不統一になっている点が指摘されている。この2つのIssueは1月16日前後に「v2.1.9で直った」というコメントとともにクローズされたが、同じスレッドの中で「v2.1.17でもまだ直っていない」という報告も混在しており、修正のロールアウトが全ユーザーに一様に届いていなかった可能性がある。今この症状が出ている場合は、まずclaude --versionで現在のバージョンを確認し、最新版へのアップデートを試すのが最短ルートだ。
症状2｜挿入はできるがフォーカスが奪われる・違う会話に切り替わる(未解決)
症状1と違って、こちらは2026年9月時点でも根本修正が確認できていない。時系列で追うと、同じ現象が名前を変えながら3回報告されている。
最初の報告(Issue #72882、2026年7月1日)
「claude-vscode.insertAtMention(Alt+K)を実行すると、挿入自体は成功するがフォーカスがClaudeのエディタタブに強制的に移る」という報告。テキストを選択して調べ物をしながらAlt+Kを押すたびにエディタ側からフォーカスを奪われるため、連続して使うとかなりのストレスになる。
再現報告(Issue #74808、2026年7月6日)
同じ症状がv2.1.201でも直っていないとして再報告された。このIssueは2026年8月31日に一度クローズされているが、理由は修正ではなく「一定期間活動がなかったため」という自動クローズ(stale bot)だった。報告者のmarcindulakは「再現手順もバージョンも書いてあるのに誤ってクローズされた」とコメントし、この自動クローズの仕組み自体の不具合を追跡する別Issue(#87647)を参照している。
複数タブ環境での再現(Issue #82098、2026年7月28日)
v2.1.219/2.1.220での報告では、症状がさらに具体化されている。同じウィンドウに複数の会話をタブとして開いている状態でAlt+Kを押すと、@メンション自体は見えている会話に正しく挿入されるのに、タブグループのアクティブタブが非表示だった別の会話に勝手に切り替わり、フォーカスもそちらに移ってしまう。報告者はバンドルされたextension.jsを実際に読んで原因を分析しており、要点は次の通りだ。
insertAtMentionは1つの共有イベントを発火させる仕組みになっている- 開いている全セッションがこのイベントを購読しており、非表示のセッションも含めて
panelTab.reveal()(preserveFocus: false)を呼んでしまう - 複数のセッションが同時に
reveal()を呼ぶため、最後に呼ばれたものが勝ち、それが「今見ていた会話」とは限らない
この報告は2026年8月15日に、メンテナのbchernyによって「#74808の重複としてクローズし、そちらに一本化する」という形で処理された。つまり実質的には未解決のまま、報告先だけが#74808に集約され、その#74808もstale botに自動クローズされている——という状態が2026年9月時点の実情になる。
症状3｜パネルを別ウィンドウに切り離すと発生する固有バグ(Issue #78698、オープン中)
2026年7月17日に報告された、より特殊な環境固有の不具合。VSCodeの「Move into New Window」でClaudeパネルを別のOSウィンドウに切り離した状態(webviewパネル、useTerminal: false)で使うと、Alt+K(claude-vscode.insertAtMention)とCtrl+Esc(claude-vscode.focus)のどちらも、ウィンドウ自体は前面に来るのに入力欄にキーボードフォーカスが入らない。クリックかTabキーを押すまでフォーカスが移らないという。
報告者による原因分析では、コマンドハンドラが単一のEventEmitterを介して全webview接続に処理を配信する設計そのものが問題とされている。ドッキングしている(同じウィンドウ内にある)状態では問題なく動くため、「ウィンドウを分けて使う」という利用スタイル自体が症状のトリガーになっている点は覚えておいたほうがいい。複数のClaudeパネルをそれぞれ別ウィンドウに切り離している場合は、1回のAlt+Kで表示中の全パネルに@メンションが二重挿入されることも確認されている。2026年9月時点でクローズされておらず、回避策も報告されていない。
おまけ｜マルチルートワークスペースでは@ファイルピッカーが最初のフォルダしか検索しない(Issue #87827)
これはフォーカスの話とは別軸の不具合だが、@メンション機能を使う上で踏みやすい落とし穴なので触れておく。2026年8月19日に報告されたIssueによると、.code-workspaceで複数のフォルダを束ねたマルチルートワークスペースを開いている場合、@メンションのファイルピッカーは最初のフォルダの中身しか候補に出さない。2番目以降のフォルダにあるファイルは、Claude自身は--add-dir経由で読み書きできるにもかかわらず、ピッカーからは選べない。
報告者がバンドルされたextension.js(v2.1.235)を解析したところ、ピッカーの検索処理は単一のルートディレクトリしか受け取らないripgrepラッパーに依存しており、フォールバック側のvscode.workspace.findFiles(全ワークスペースフォルダを正しく検索できる実装)を使っていないことが原因として特定されている。複数リポジトリを1つのワークスペースにまとめて開発しているなら、2番目以降のフォルダのファイルは@で探さずファイル名を直接タイプするか、エクスプローラーからドラッグ&ドロップで添付するほうが確実だ。
なぜこの手の「フォーカスを奪う」バグが多いのか
症状2・症状3を個別に追っていると偶然の重なりに見えるが、実はもっと大きな構造的な問題として認識されている。2026年8月16日に登録されたIssue #87053は、「入力中にダイアログやパネルがキーボードフォーカスを奪う」という同種の不具合を、2025年6月4日から2026年8月14日までの14か月間で52件洗い出し、うち18件が未解決のまま放置されていたことを報告している。対象はVSCode拡張だけでなく、ターミナルUI・JetBrainsプラグイン・デスクトップアプリ・TUIすべてに及ぶ。この報告では過去に同じ問題を指摘していた3件の機能要望(いずれもクローズ済み)が互いにリンクされないまま個別に処理されていたことも指摘されている。
つまりAlt+Kのフォーカス問題は独立したバグというより、「新しいUI要素が表示される直前に、ユーザーが入力中かどうかをチェックしていない」という設計上の穴が、機能ごとに形を変えて表面化しているケースの1つと見たほうが実情に近い。
現実的な回避策
根本修正を待つ間、実務でストレスを減らすなら次の対応が現実的だ。
- 会話タブを複数開いている状態でのAlt+K多用を避ける。1つの会話に集中している間だけ他のタブを閉じておくと、フォーカスの誤動作は起きにくい
- Claudeパネルを別ウィンドウに切り離す運用(症状3)は今のところ避け、同一ウィンドウ内のタブ/サイドバー運用にとどめる
- ショートカットが完全に無反応になった場合は、コマンドパレット(
Cmd+Shift+P/Ctrl+Shift+P)からClaude Code: Insert @-Mention Referenceを直接実行できるか確認する。実行できるならキーバインド側の問題、実行してもエラーになるなら拡張機能自体の不具合と切り分けられる - マルチルートワークスペースでは
@ピッカーに頼らず、ファイル名の直接入力かドラッグ&ドロップで添付する - どのバージョンでも改善しない場合は、
claude --versionを控えたうえで最新版にアップデートしてから再確認する(症状1の回帰は都度修正されているため、古いバージョンのまま使い続けるのが一番損をしやすい)
それでも直らないときに集める情報
ここまでの症状に当てはまらない、あるいは対処しても直らない場合は、次の情報を揃えてGitHub Issueを検索するか新規報告したほうが早い。
claude --version- OS(macOS/Windows/Linux)とバージョン
- VSCodeのバージョン、Claude Code拡張のバージョン
- 会話タブを複数開いているか、Claudeパネルを別ウィンドウに切り離しているか
- マルチルートワークスペース(
.code-workspace)を使っているか - 既存Issue(#74808、#78698、#87827など)に該当する再現手順があれば、新規報告よりそちらへの👍とコメント追加のほうが優先度が上がりやすい
FAQ
「Issueがクローズされている」ならもう直っているということ?
必ずしもそうとは言えない。この記事で扱った#74808と#82098は、どちらも「修正されたから」ではなく「重複としての一本化」または「一定期間活動がなかったための自動クローズ」でクローズされている。クローズ済みIssueを見つけても、コメント欄まで読んで実際に修正版が出たと確認できるまでは「直った」と判断しないほうがいい。
Windows/Mac/Linuxで症状に違いはある?
キー自体はOption+K(Mac)/Alt+K(Windows/Linux)で共通だが、Windows版はVSCode本体の別機能(recordSearchKeysなど)とのキー競合が絡むケースが報告されている一方、Mac版は複数タブ間のフォーカス制御に起因する報告が中心になっている。プラットフォーム差を疑う前に、まずコマンドパレットからの直接実行で切り分けるのが早い。
ショートカットを別のキーに変更すれば回避できる?
キーが反応しない(症状1)場合は有効な回避策になりうる。VSCodeのキーボードショートカット設定(Cmd+K Cmd+S)でClaude Code: Insert @-Mention Referenceを検索し、競合しないキーに割り当て直せばいい。ただし症状2・症状3のフォーカス制御の不具合はキーバインドの問題ではなく拡張機能内部のロジックに起因するため、キーを変えても解消しない。
まとめ
Alt+K(Option+K)の「反応しない」系トラブルは過去に複数回のバージョン回帰が起きたが、その都度修正が入っており、最新版へのアップデートで解消するケースが大半だ。一方で「挿入はできるがフォーカスが変な場所に飛ぶ」系のトラブルは、2026年7月の最初の報告から2か月以上経った9月時点でも根本修正が確認できておらず、しかもIssue管理側の自動クローズの仕組みによって「解決していないのにクローズされている」という分かりにくい状態になっている。会話タブを複数開く運用やパネルを別ウィンドウに切り離す運用をしているなら、こうした既知の制限があることを踏まえたうえで、コマンドパレット実行への切り替えなど現実的な回避策で凌ぐのが今のところの最適解になる。
VSCode拡張全体の実務ワークフローは別記事にまとめているので、あわせて読んでほしい。
