code-oss-logs

Code OSS のログ

直近の Code OSS または Agents アプリの開発実行のログを検索して表示します。

ログのルートディレクトリ

アプリ	デフォルトのユーザーデータディレクトリ	ログのパス
Code OSS	$HOME/.vscode-oss-dev	$HOME/.vscode-oss-dev/logs/
Agents app	$HOME/.vscode-oss-dev	$HOME/.vscode-oss-dev/logs/

Code OSS を --user-data-dir=<dir> を指定して起動した場合は、上記のデフォルトではなく <dir>/logs/ を使用してください。起動やデバッグのヘルパーによっては、.build/ の下に一時的なユーザーデータディレクトリが作成されることがあります。起動コマンドから正確なユーザーデータディレクトリがわかる場合は、必ずそちらを優先してください。

実行のたびに、20260330T163430 のようなタイムスタンプ付きフォルダーが作成されます。変更時刻順で最も新しいフォルダーが、通常、ユーザーが確認したいログです。

手順

1. ユーザーがどのアプリについて尋ねているかを特定します。Code OSS または Agents app です。不明な場合は両方を確認します。
2. 最も新しいログフォルダーを見つけます：

   ls -lt "$HOME/.vscode-oss-dev/logs" | head -5
   # またはカスタムのユーザーデータディレクトリの場合：
   ls -lt "<user-data-dir>/logs" | head -5
   

3. 最も新しいフォルダーに移動し、内容を一覧表示します。
4. 調査内容に応じて、関連するログファイルを読みます。最近のエントリには tail を、絞り込みには rg を使用します。

ディレクトリ構成

各タイムスタンプ付きログフォルダーには、次の構成があります。

<timestamp>/
├── main.log                    # Electron main process (app lifecycle, window management)
├── agenthost.log               # Agent host process (Copilot agent, model listing, agent sessions)
├── mcpGateway.log              # MCP gateway/server coordination
├── sharedprocess.log           # Shared process (extensions gallery, global services)
├── telemetry.log               # Telemetry events
├── terminal.log                # Terminal/pty activity
├── ptyhost.log                 # Pty host process
├── network-shared.log          # Shared network activity
├── editSessions.log            # Edit sessions / cloud changes
├── userDataSync.log            # Settings sync
├── remoteTunnelService.log     # Remote tunnel service
│
└── window1/                    # Per-window logs (window1, window2, etc.)
    ├── renderer.log            # Renderer process (workbench UI, services, startup)
    ├── network.log             # Per-window network activity
    ├── views.log               # View/panel activity
    ├── notebook.rendering.log  # Notebook rendering
    ├── customizationsDebug.log # Agent customizations debug info (Agents app)
    ├── mcpServer.*.log         # Per-MCP-server logs (one file per configured server)
    │
    ├── exthost/                # Extension host logs
    │   ├── exthost.log         # Extension host main log (activation, errors)
    │   ├── extHostTelemetry.log
    │   ├── <publisher.extension>/  # Per-extension log folders
    │   │   └── <extension>.log
    │   └── output_logging_<timestamp>/  # Extension output channels
    │
    └── output_<timestamp>/     # Output channel logs (workbench side)
        ├── tasks.log           # Tasks output
        ├── agentSessionsOutput.log  # Agent sessions output (Agents app)
        └── agenthost.<clientId>.log  # Agent host IPC traffic when tracing is enabled

複数の output_ フォルダー

同じセッション内でウィンドウが再読み込みされるたびに、新しい output_<timestamp>/ フォルダーと、exthost/ 内に対応する output_logging_<timestamp>/ フォルダーが作成されます。20260330T163430/ のようなセッション単位のタイムスタンプ付きフォルダーは同じままですが、再読み込みのたびに新しい出力チャンネルのディレクトリが作成されます。タイムスタンプが最も新しい output_* フォルダーに、現在または直近の再読み込みのログがあります。それ以前のフォルダーには、そのセッション内で過去に再読み込みした際のログがあります。

Cloud Sandbox の起動失敗

まず renderer.log を確認します。[CloudSandboxApi] の接続／再接続に関する HTTP エラーには、ステータス、経過時間、利用可能な場合は環境 ID／セッション ID／クライアント ID、および X-GitHub-Request-Id から検証された requestId が記録されます。このリクエスト ID を使うと、該当する上流の HTTP リクエストを特定できます。環境 ID／セッション ID は再試行や非同期処理にも引き継がれます。リクエスト ID がない場合は、応答ヘッダーが存在しないか、ブラウザーからアクセスできないことを示している可能性があります。

[WebPubSubRelayTransport] と [RemoteAgentHostProtocol] のログから、返された clientId を追跡します。リレーの準備完了、最初のパブリッシュ確認応答、最初のホストフレーム、AHP の初期化リクエスト／完了を確認すると、リレーのセットアップとホストの応答性を区別できます。リレーのパブリッシュ確認応答だけでは、ホストが処理を実行したことの証明にはなりません。リレーの終了時のサマリーには、未処理の確認応答、ホストフレーム／メッセージ数、ホストからの応答がない時間、プロトコル／再構成エラーの数が記録されます。認証情報やペイロードは記録されません。これらの記録は通常のログサービス出力であり、AHP ペイロードのログ記録は必要ありません。

用途別の主要ファイル

調査内容...	確認するファイル
アプリの起動／クラッシュ	main.log、window1/renderer.log
拡張機能の問題	window1/exthost/exthost.log、window1/exthost/<publisher.ext>/
Copilot／エージェントの問題	agenthost.log、window1/exthost/GitHub.copilot-chat/
エージェントホストの IPC（Agents app）	window1/output_<timestamp>/agenthost.*.log
MCP サーバーの問題	mcpGateway.log、window1/mcpServer.*.log
ターミナルの問題	terminal.log、ptyhost.log
ネットワーク／認証の問題	network-shared.log、window1/network.log
設定の同期	userDataSync.log
エージェントのカスタマイズ	window1/customizationsDebug.log（Agents app）

便利なコマンド

# Recent entries from a log file
tail -50 "<timestamp>/window1/renderer.log"

# Search all logs in a run for a probe marker or error
rg -n "MY_PROBE|error" "<timestamp>"

# Show non-empty logs in a run
find "<timestamp>" -type f -size +0 -print

一時的なコンソール転送のワークフロー

一時的な console.log のプローブを使用しており、それらを通常のログファイルにも記録する必要がある場合は、Code OSS を起動する前に、ローカルで開発用コンソール転送を有効にしてください。

1. src/vs/platform/log/common/log.ts で、isDevConsoleLogForwardingEnabled を見つけます。
2. コメントアウトされている Boolean("true") の行を一時的に有効にします。

   export const isDevConsoleLogForwardingEnabled = false
       || Boolean("true") // done "weirdly" so that a lint warning prevents you from pushing this
       ;
   

3. ビルドするか、ウォッチタスクで変更を反映させます。
4. Code OSS または Agents アプリを起動し、問題を再現します。
5. 該当するログを確認します。
6. 作業を終える前に、フラグを既定の無効状態に戻し、一時的な console.log のプローブをすべて削除します。

Boolean("true") の形式は、意図的にリンターで警告が出るようにしています。有効のまま誤ってチェックインされるのを防ぐためです。このフラグを有効にしたままチェックインしないでください。

ヒント

• ソースビルドで一時的な開発用プローブを使用する場合は、console.log と ILogService のどちらでも構いません。作業中のコードで使いやすい方を使用してください。
• console.log のプローブをチェックインしてはいけません。ログ出力コードを製品に残す場合は、代わりに ILogService を使用してください。
• ソースビルドで開発用コンソール転送が有効になっている場合、console.debug、console.error、console.info、console.log、console.warn の出力は、プロセスログサービスを通じて通常のログファイルに書き込まれます。
• コンソールのプローブは、出力したプロセスのログに記録されます。メインプロセスは main.log、レンダラー／ワークベンチは window1/renderer.log、共有プロセスは sharedprocess.log、PTY ホストは ptyhost.log、エージェントホストは agenthost.log に記録されます。拡張機能ホストのコンソール出力はレンダラー側で監視され、拡張機能ホストのすべてのコンソール出力の転送が有効になっている場合は、window1/renderer.log に表示されます。
• コンソール転送が有効でない場合、ログファイルに確実に記録する必要があるプローブには ILogService を使用してください。ネイティブの console.log の出力は、DevTools または stdout にしか表示されない場合があります。
• すべてのログファイルに内容があるとは限りません。多くのログファイルは空の状態で作成され、該当するサブシステムが出力を生成した場合にのみ内容が書き込まれます。
• window1/ は最初のウィンドウです。複数のウィンドウを開いている場合は、window2/ なども作成されます。
• ログ行の形式は YYYY-MM-DD HH:MM:SS.mmm [level] message です。