Cursor VS Codeのログイン障害を公式記録と入口で確認する
cursor vscodeでログインできないときは、Cursor公式に記録された障害と、VS Codeの拡張や手元のアカウント表示を同じものとして扱わないことが重要です。2026年9月7日の公式記録をUTC・日本時間で照合し、Cursor IDE、VS Code拡張、CLIを分けて確認する順序をまとめます。CodexやCopilotなど別製品は、公式情報を分けて切り分けます。
2026年9月7日のCursor公式インシデントは、CLI・Cloud Agents・IDEが対象でした。公式記録では12:12–13:08 UTC、日本時間では21:12–22:08に、ログインまたはアカウント関連のエラーが起きる可能性があり、13:08 UTCに解消済みとされています。出典: https://status.cursor.com/incidents/nk7ln2sb6n6q
ただし、公式ページにVS Code固有の拡張だけが停止したとは書かれていません。Cursor IDE、VS Codeの拡張、Cursor CLIは別の入口として、どこで再現したか、同じアカウント表示だったか、短い確認作業が通ったかを分けて記録します。現在の状態は https://status.cursor.com/ で確認できます。
Codex、OpenAI、GitHub Copilot、Copilot CLI、Gemini CLI、Aiderの情報はCursorの記録に置き換えられません。 Codex 0.153.4、Copilot CLI 1.0.83 / 1.0.84-1、Gemini CLIのnightly版、Aider v0.86.0は、それぞれの版と公式ページを別行で確認します。比較材料を同じ障害の証拠として扱わないことが重要です。
目次 (19)
- 2026年9月7日の公式記録で確定できる範囲
- cursor vscodeで検索した人が最初に残す記録
- Cursor IDE・VS Code拡張・CLIを同じ入口と見なさない
- 公式ステータスと手元の問題を切り分ける順番
- VS Code拡張で再現する場合の確認
- 公式掲載にないことを断定しない
- VS Code拡張だけの障害だった
- 9月8日も継続している
- CodexやCopilotも同じ原因だった
- Codex・OpenAI・Copilot・各CLIの情報を分けて確認する
- 復旧後に行う確認と保存する結果
- 次回のための記録テンプレート
- よくある質問
- VS Codeでログインできないなら、VS Code全体の障害ですか？
- 9月7日の時間帯に当てはまれば、原因はCursorで確定しますか？
- Cursorが復旧済みなのにログインできません。何を見ますか？
- Codexも同じ時間に止まりました。Cursorの障害ですか？
- すぐに版を更新すれば直りますか？
- まとめ
2026年9月7日の公式記録で確定できる範囲
今回の検索語は「cursor vscode」ですが、最初に読むべき一次情報はCursorの公式ステータスです。インシデントの見出しは「Investigating service degradation — CLI, Cloud Agents, and IDE」で、解消時の説明には、指定された時間帯に一部利用者がログインまたはアカウント関連のエラーを経験した可能性があり、すべてのサービスが通常状態へ戻ったとあります。出典: https://status.cursor.com/incidents/nk7ln2sb6n6q
公式掲載から読み取れる事実と、そこからは言えないことを表に分けます。
| 確認項目 | 公式記録から分かること | この記録だけでは言えないこと |
|---|---|---|
| 対象 | CLI、Cloud Agents、IDEでログインまたはアカウント関連のエラーが起きる可能性 | VS Code拡張だけが原因だったこと |
| 発生時間 | 12:12–13:08 UTC、21:12–22:08 JST | この時間帯以外にも同じ状態が続いたこと |
| 解消時刻 | 13:08 UTCの更新で解消済み、全サービスが通常状態へ復帰 | 個々の端末やアカウントが必ず正常になったこと |
| 2026年9月8日の状態 | 公式トップページはAll Systems Operationalと表示 | 次の発生がないこと、手元の問題がサービス側でないこと |
日本時間への換算は、発生時刻を記録した利用者が公式掲載と照合するためのものです。9月7日21:30にログインできなかったなら対象時間の中に入りますが、22:30に同じ問題が起きた場合は、このインシデントだけで説明できるとは限りません。まず発生時刻をUTCとJSTの両方で残し、別の掲載や手元の入口へ調査を戻します。
なお、公式トップページで通常稼働と表示されていても、特定の利用者、モデル、入口、地域の状況まで保証する表示ではありません。OpenAI Statusも、可用性の数値は全体の集計であり、契約やモデル、機能によって個別の状態が異なる場合があると説明しています。公式状態は「広い範囲の事象か」を判断する材料として使い、手元の再現確認と混同しないようにします。出典: https://status.openai.com/
cursor vscodeで検索した人が最初に残す記録
ログインできないときに、いきなり再インストールや設定変更へ進むと、最初に出ていた表示が消えてしまいます。次の項目を短く残すだけで、公式の時間帯と自分の発生条件を比較しやすくなります。
| 記録項目 | 書き方の例 | 確認の意味 |
|---|---|---|
| 発生時刻 | 2026-09-07 21:35 JST / 12:35 UTC | 公式インシデントの時間帯と照合する |
| 入口 | Cursor IDE、VS Codeの拡張、Cursor CLIのどれか | どのサービス経路で起きたかを分ける |
| 画面の文言 | ログイン画面に戻る、アカウントが表示されない、接続待ち | 推測ではなく観測した動作を残す |
| アカウント表示 | 表示された名前、未表示、切り替わった表示 | アカウント状態とサービス状態を分ける |
| 作業場所 | 新しい小さなフォルダー、既存のプロジェクト | プロジェクト固有の条件を比べる |
| 最後に成功した操作 | ファイルを読む、質問を送る、変更を確認する | 失敗直前の境界を探す |
画面の文言は、記憶で言い換えず、可能ならそのままメモします。「入れない」「壊れた」だけでは、ログイン画面へ戻ったのか、応答だけが止まったのか分かりません。発生時刻、入口、表示、最後に成功した操作を一組にしておくと、後で公式情報へ戻ったときに比較できます。
Cursor IDE・VS Code拡張・CLIを同じ入口と見なさない
Cursor IDEを使っていた場合、公式インシデントの「IDE」という対象には重なります。しかし、VS Codeの中で別の拡張を使っていた場合は、エディター本体、拡張ホスト、拡張の版、接続先を個別に確認する必要があります。Cursor CLIを端末から使っていた場合も、画面のログイン表示とCLIの表示が同じになるとは限りません。
入口ごとの最初の確認を次のように分けます。
| 入口 | 最初に見るもの | 結果から言える範囲 |
|---|---|---|
| Cursor IDE | 公式ステータス、ログイン表示、短い読み取り | Cursor IDEの入口で再現したかを確認できる |
| VS Codeの拡張 | 拡張名・版、無効化の有無、拡張ホストの状態 | VS Code側の入口で再現したかを確認できる |
| Cursor CLI | CLIの版、ログイン表示、同じアカウントでの短い読み取り | 端末の入口で再現したかを確認できる |
VS Code公式ドキュメントでは、拡張はVS CodeのUIへ機能を追加する仕組みで、拡張の詳細画面から版や変更履歴を確認できます。また、コマンドラインでは code --list-extensions と code --show-versions でインストール済み拡張と版を確認でき、拡張ごとの無効化や拡張ホストの再起動も案内されています。出典: https://code.visualstudio.com/docs/configure/extensions/extension-marketplace
このため、VS Code拡張でだけログイン表示が崩れ、Cursor IDEやCLIで同じアカウントが使えるなら、公式インシデントの対象時間に重なっていたとしても、拡張固有の条件を別に調べます。逆に、複数の入口で同じ時間に同じアカウント関連の表示が出たなら、公式記録との一致度は高まります。ただし、一度入口を変えて成功しただけで原因が確定したとは扱いません。
公式ステータスと手元の問題を切り分ける順番
確認は影響の小さい順に進めます。目的は、問題を大きく再現することではなく、どの層で失敗しているかを一つずつ確かめることです。
- 公式状態を見る。 Cursorのトップページと過去インシデントを開き、現在の表示、掲載された対象、発生時刻、解消時刻を記録します。今回の記録なら
12:12–13:08 UTCと21:12–22:08 JSTを一行に並べます。 - 入口を固定する。 Cursor IDE、VS Code拡張、CLIを一度に比較せず、まず実際に使っていた入口を一つ確認します。別の入口へ移るのは比較のためで、移った結果を原因の確定とは扱いません。
- アカウント表示を確認する。 ログイン画面へ戻ったのか、別のアカウント表示になったのか、単に作業結果が返らなかったのかを分けます。アカウント表示が戻っているかだけで、作業の成功までは判断しません。
- 短い読み取りを試す。 新しい小さな作業場所で、ファイルを読むだけの確認を行います。書き込みを伴う大きな依頼を繰り返すと、サービス側の問題と作業内容の問題が混ざります。
- 結果を残す。 成功した入口、失敗した入口、表示された版、公式ページを一つの記録にまとめます。復旧していても、最初の失敗時刻とその後の成功時刻を消さないことが大切です。
公式ステータスが通常稼働へ戻った後も、手元で問題が続くことはあります。拡張の読み込み、アカウント表示、ネットワーク、端末の負荷、作業場所の条件を順番に見て、再現条件が狭くなるかを確認します。設定を広く変える前に、変更前の状態を保存しておけば、直った理由を説明できます。
VS Code拡張で再現する場合の確認
VS Code拡張の問題を調べるときは、まず拡張の名前と版を記録します。VS Code公式ドキュメントには、特定の版を選んで入れる方法、拡張を一時的に無効化する方法、拡張の動作を分けて確認するExtension Bisectが案内されています。これらは「VS Codeで起きた」という観測を、どの拡張のどの版で起きたかへ細かくするために使います。出典: https://code.visualstudio.com/docs/configure/extensions/extension-marketplace
確認の順序は、次のように狭い範囲から始めます。
- 拡張の詳細画面で名前、提供元、版、更新日を記録する。
- 同じアカウント表示で、変更を加えない短い読み取りを試す。
- 拡張を無効化した場合にVS Code本体が開くかを確認する。ただし、無効化で直っても原因が確定したとは書かない。
- 新しい小さな作業場所で同じ表示が出るかを比べる。
- 公式インシデントの対象時間と、拡張側の記録を並べる。
VS Codeの公式ページは、拡張にはVS Code本体と同じ権限があること、第三者提供元の拡張を初めて入れるときに提供元を信頼する確認が表示されることも説明しています。ログイン障害を調べるときに、拡張の版や提供元を記録するのは、サービス全体の問題と手元の拡張条件を分けるためです。ここで別の拡張を追加したり、複数の設定を同時に変えたりする必要はありません。
公式掲載にないことを断定しない
今回の公式記録からは、次の三つを断定できません。
VS Code拡張だけの障害だった
公式の対象表記はCLI、Cloud Agents、IDEです。そこにVS Codeという固有の拡張名はありません。VS Code拡張を使っていた人が対象時間にログインできなかった可能性はありますが、拡張だけが原因だったとは書けません。記事や報告では「VS Codeで起きた」と短縮せず、「どの入口で、何が表示されたか」を残します。
9月8日も継続している
公式インシデントは13:08 UTCに解消済みとされ、9月8日のトップページは通常稼働を示しています。9月8日に同じ表示が出た場合は、9月7日の記録を参考にしながら、新しい発生時刻と入口を記録します。過去の解消済み記録を、そのまま現在の継続障害として引用しないことが大切です。出典: https://status.cursor.com/
CodexやCopilotも同じ原因だった
Cursorの公式ページは、Cursorのサービス入口についての記録です。Codex、GitHub Copilot、Copilot CLI、Gemini CLI、Aiderで同じ時間に失敗したとしても、それぞれの公式状態と版を確認しなければ、同じ原因とは言えません。製品名が近いことや、同じエディターで使っていることは、原因が同一である証拠になりません。
Codex・OpenAI・Copilot・各CLIの情報を分けて確認する
ブリーフの対象窓には、Cursorと同じコード作業で使われる複数の製品情報もあります。ここでは、Cursorの障害と混ぜずに、各公式ページで確認できる版や状態を記録します。
| 製品・入口 | 2026年9月8日に確認する基準 | Cursorの記録と混同しない点 | 出典 |
|---|---|---|---|
| Codex | 公式リリースの0.153.4を参照点にする。Astraの表示とツール利用条件に関する修正が記載されている | Cursorのログイン障害をCodexの版更新や障害情報へ置き換えない | https://github.com/openai/codex/releases/tag/rust-v0.153.4 |
| OpenAI Status | 全体状態と個別環境の表示を分ける | OpenAIが通常稼働でもCursorの入口の状態は決まらない | https://status.openai.com/ |
| GitHub Copilot CLI | 1.0.83は9月4日公開のLatest、1.0.84-1は同日公開のPre-releaseとして別に扱う | Copilot CLIの版や表示条件をCursor IDE・VS Code拡張へ移さない | https://github.com/github/copilot-cli/releases |
| Gemini CLI | v0.60.0-nightly.20260907.g85aca163fが9月7日01:27 UTCに公開されたnightly版。前日版との比較先が案内される | nightly版の公開をCursor障害の原因としない | https://github.com/google-gemini/gemini-cli/releases/tag/v0.60.0-nightly.20260907.g85aca163f |
| Aider | 公式リリース欄の確認点はv0.86.0。9月7日の対象窓の新着としては扱わない | Aiderの版や接続結果をCursor・Codexの状態へ置き換えない | https://github.com/Aider-AI/aider/releases/tag/v0.86.0 |
Codex 0.153.4の公式リリースは、同梱モデル選択画面でAstraを表示し、明示的なモデル設定がない場合の同梱既定値にする修正と、利用できる道具があるセッションに限って非同期の質問案内を使う修正を挙げています。これはCodexの入口の変更であり、Cursorのログイン記録とは別です。出典: https://github.com/openai/codex/releases/tag/rust-v0.153.4
Copilot CLIについては、1.0.83に「Latest」として複数の更新が記載され、1.0.84-1は「Pre-release」でAstra対応が記載されています。安定版と先行版を混ぜず、どの版を使っていたかを記録します。9月4日の公開情報を、9月7日のCursorインシデントの原因とは結び付けません。出典: https://github.com/github/copilot-cli/releases/tag/v1.0.83 / https://github.com/github/copilot-cli/releases/tag/v1.0.84-1
Gemini CLIのnightlyページは9月7日01:27 UTCに公開され、前日のnightly版との比較先を示しています。個別の変更説明を版番号だけで補わず、nightlyを日常利用の安定版と同じ前提にも置きません。Aider v0.86.0は8月9日公開のLatestとして確認でき、対象窓の新着情報ではありません。出典: https://github.com/google-gemini/gemini-cli/compare/v0.60.0-nightly.20260906.g85aca163f...v0.60.0-nightly.20260907.g85aca163f / https://github.com/Aider-AI/aider/releases/tag/v0.86.0
Cursorの変更履歴も、サービス状態とは別の資料です。9月2日の変更履歴に新しい機能の掲載があっても、9月7日のログイン関連インシデントの原因や対象範囲を説明するものではありません。機能の公開、障害の発生、障害の解消は、それぞれの一次情報に分けて引用します。出典: https://cursor.com/changelog
復旧後に行う確認と保存する結果
公式ページで解消済みになった後は、同じ操作を何度も繰り返すより、一度の短い確認を記録します。確認結果は「ログインできた」「応答が返った」「作業が完了した」を分けて書きます。ログイン表示が戻っても、別の入口や別の作業場所の状態まで正常とは限りません。
- 公式ステータスの確認日時とURLを保存する。
- 使っていた入口と、入口の版番号を保存する。
- アカウント表示が戻ったか、別表示になっていないかを確認する。
- 新しい小さな作業場所で読み取りだけを一度試す。
- 必要なら小さな変更を一つだけ行い、差分と結果を確認する。
- 成功した時刻と、まだ確認できていない入口を記録する。
小さな確認が成功しても、大きな作業まで同じ結果になると断定しません。反対に、短い読み取りだけが失敗した場合も、公式障害、アカウント表示、入口、ネットワーク、作業場所を分けて見ます。版を更新する場合は、更新前の版と更新後の版を残し、どの変更が結果に影響したかを後から比べられるようにします。
次回のための記録テンプレート
再発時は、次の項目を埋めてから公式ページと照合します。個人情報や非公開のコードをそのまま共有せず、画面の文言と必要な環境情報だけを残します。
発生日:
発生時刻 UTC:
発生時刻 JST:
入口: Cursor IDE / VS Code拡張 / Cursor CLI / その他
入口の版:
画面の文言:
アカウント表示:
最後に成功した操作:
公式ステータスURL:
公式記録と一致した点:
一致しなかった点・未確認:
復旧後に成功した操作:
この記録には「原因」と書く欄を先に設けず、まず観測した事実を書きます。公式ページに対象時間と入口が示されている場合は、発生時刻と入口を照合し、合わない部分を未確認として残します。推測を事実の欄へ入れないことが、次回の比較を簡単にします。
よくある質問
VS Codeでログインできないなら、VS Code全体の障害ですか？
いいえ。VS Code本体、インストールされた拡張、拡張ホスト、Cursorのサービス入口は分けて考えます。まず拡張名と版、公式ステータス、発生時間、ログイン表示を残し、Cursor IDEやCLIで同じアカウントが使えるかを比較します。別の入口が成功しても、それだけで原因を確定しないでください。
9月7日の時間帯に当てはまれば、原因はCursorで確定しますか？
公式記録との時間の一致は重要な手掛かりですが、入口と表示も必要です。12:12–13:08 UTCの間にCLI・Cloud Agents・IDEでログインまたはアカウント関連のエラーが起きた可能性が記録されています。一方、端末のネットワークや拡張の問題まで同じ原因だと決めることはできません。
Cursorが復旧済みなのにログインできません。何を見ますか？
まず新しい発生時刻、使っている入口、画面の文言、アカウント表示を残します。その後、公式トップページを確認し、Cursor IDE・VS Code拡張・CLIのどこで再現するかを一つずつ比べます。拡張の版や有効状態、作業場所、端末の接続条件も、複数同時に変えずに確認します。
Codexも同じ時間に止まりました。Cursorの障害ですか？
そうとは限りません。Codexの版、OpenAI Status、利用していた入口、画面の表示を別に確認します。Codex 0.153.4のリリース情報やOpenAI Statusは、Cursorのサービス状態を直接説明する資料ではありません。製品ごとの公式記録と手元の時刻が一致するかを分けて見ます。
すぐに版を更新すれば直りますか？
更新前の版と発生条件を残す前に版を変えると、原因と変更が混ざります。まず公式情報、入口、アカウント表示、短い読み取りの順で確認し、必要性がはっきりしたときだけ版を分けて試します。安定版と先行版がある製品は、同じものとして扱いません。
まとめ
cursor vscodeでログインできなかったときは、まずCursor公式が示した対象、時間、解消時刻をUTCと日本時間で照合します。2026年9月7日の記録はCLI・Cloud Agents・IDEを対象に12:12–13:08 UTCの可能性を示し、13:08 UTCに解消済みとしています。公式トップページが通常稼働でも、手元のVS Code拡張やアカウント表示まで一律に正常とは限らないため、入口と画面の事実を別に残します。出典: https://status.cursor.com/incidents/nk7ln2sb6n6q
次に、Cursor IDE、VS Code拡張、Cursor CLIを分け、発生時刻、版、画面の文言、最後に成功した操作を記録します。Codex、OpenAI、GitHub Copilot、Copilot CLI、Gemini CLI、Aiderの情報は、各公式ページを基準に別製品として確認します。新しい情報を見つけたことと、自分の入口で使えることを分けて書くことが、次のログイン問題を短く確認するための土台になります。
