code-oss-logs

작성자: microsoft

Code OSS 개발 빌드에서 로그를 찾고 읽습니다. 사용 시기: 로그 찾기, 로그 파일 읽기, Code OSS 디버깅, 렌더러 로그 확인, 확장 호스트 로그, 에이전트…

npx skills add https://github.com/microsoft/vscode --skill code-oss-logs

Code OSS Logs

Find and display logs from the most recent Code OSS or Agents app dev run.

Log Root Directories

AppDefault User Data DirLogs Path
Code OSS$HOME/.vscode-oss-dev$HOME/.vscode-oss-dev/logs/
Agents app$HOME/.vscode-oss-dev$HOME/.vscode-oss-dev/logs/

If Code OSS was launched with --user-data-dir=<dir>, use <dir>/logs/ instead of the defaults above. Launch and debugging helpers often create temporary user data dirs under .build/; always prefer the exact user data dir from the launch command when it is known.

Each run creates a timestamped folder like 20260330T163430. The most recent folder sorted by modification time is usually the one the user cares about.

Procedure

  1. Identify which app the user is asking about: Code OSS or Agents app. If unclear, check both.
  2. Find the most recent log folder:
    ls -lt "$HOME/.vscode-oss-dev/logs" | head -5
    # or for a custom user data dir:
    ls -lt "<user-data-dir>/logs" | head -5
    
  3. Navigate into the most recent folder and list contents.
  4. Read the relevant log file(s) based on what the user is investigating. Use tail for recent entries or rg to filter.

Directory Layout

Each timestamped log folder has this structure:

<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

Multiple output_ Folders

A new output_<timestamp>/ folder and a corresponding output_logging_<timestamp>/ inside exthost/ is created each time the window reloads within the same session. The session-level timestamped folder, such as 20260330T163430/, stays the same, but each reload gets fresh output channel directories. The most recent output_* folder by timestamp has the logs for the current or latest reload. Earlier folders contain logs from prior reloads in that session.

Key Files by Use Case

Investigating...Check these files
App startup / crashesmain.log, window1/renderer.log
Extension issueswindow1/exthost/exthost.log, window1/exthost/<publisher.ext>/
Copilot / agent issuesagenthost.log, window1/exthost/GitHub.copilot-chat/
Agent host IPC (Agents app)window1/output_<timestamp>/agenthost.*.log
MCP server problemsmcpGateway.log, window1/mcpServer.*.log
Terminal problemsterminal.log, ptyhost.log
Network / auth issuesnetwork-shared.log, window1/network.log
Settings syncuserDataSync.log
Agent customizationswindow1/customizationsDebug.log (Agents app)

Useful Commands

# 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

Temporary Console Forwarding Workflow

When using temporary console.log probes and you need those probes to persist in the normal log files, enable dev console forwarding locally before launching Code OSS.

  1. In src/vs/platform/log/common/log.ts, find isDevConsoleLogForwardingEnabled.
  2. Temporarily enable the commented Boolean("true") line:
    export const isDevConsoleLogForwardingEnabled = false
        || Boolean("true") // done "weirdly" so that a lint warning prevents you from pushing this
        ;
    
  3. Build or let the watch task pick up the change.
  4. Launch Code OSS or the Agents app and reproduce the issue.
  5. Read the relevant logs.
  6. Before finishing, restore the flag to its default-off state and remove every temporary console.log probe.

The Boolean("true") form is intentionally lint-hostile so an accidentally enabled flag should be caught before check-in. Do not check in this flag enabled.

Tips

  • For temporary dev probes in source builds, either console.log or ILogService is fine. Use whichever is easiest in the code you are touching.
  • console.log probes must never be checked in. If logging code is intended to stay in the product, use ILogService instead.
  • If dev console forwarding is enabled in the source build, console.debug, console.error, console.info, console.log, and console.warn are written through the process log service into the normal log files.
  • Console probes land in the log for the process that emitted them: main process in main.log, renderer/workbench in window1/renderer.log, shared process in sharedprocess.log, pty host in ptyhost.log, and agent host in agenthost.log. Extension host console output is observed from the renderer side and appears in window1/renderer.log when forwarding all extension-host console output is enabled.
  • If console forwarding is not enabled, use ILogService for probes that must persist in the log files; native console.log may only appear in DevTools or stdout.
  • Not all log files have content. Many are created empty and only populated if that subsystem produces output.
  • window1/ is the first window; multi-window sessions will have window2/, etc.
  • Log lines follow the format: YYYY-MM-DD HH:MM:SS.mmm [level] message.

microsoft의 다른 스킬

oss-growth
microsoft
OSS 성장 해커 페르소나
agent-framework-azure-ai-py
microsoft
Microsoft Agent Framework Python SDK(agent-framework-azure-ai)를 사용하여 Azure AI Foundry 에이전트를 구축합니다. AzureAIAgentsProvider로 지속적 에이전트를 만들 때, 호스팅 도구(코드 인터프리터, 파일 검색, 웹 검색)를 사용할 때, MCP 서버를 통합할 때, 대화 스레드를 관리할 때, 또는 스트리밍 응답을 구현할 때 사용합니다. 함수 도구, 구조화된 출력, 다중 도구 에이전트를 다룹니다.
development
airunway-aks-setup
microsoft
AKS에서 AI Runway 설정 — 빈 클러스터에서 실행 중인 모델까지. 클러스터 검증, 컨트롤러 설치, GPU 평가, 공급자 설정, 첫 배포를 다룹니다. 시기: "AI Runway 설정", "AKS 클러스터 온보딩", "AI Runway 설치", "airunway 설정", "AKS에 모델 배포", "AKS에서 GPU 추론", "AKS에서 KAITO 설정", "AKS에서 LLM 실행", "AKS에서 vLLM", "AKS에서 모델 서빙 설정", "AI Runway 컨트롤러".
devops
appinsights-instrumentation
microsoft
Azure Application Insights로 웹앱을 계측하기 위한 지침입니다. 원격 분석 패턴, SDK 설정, 구성 참조를 제공합니다. WHEN: 앱 계측 방법, App Insights SDK, 원격 분석 패턴, App Insights란 무엇인가, Application Insights 지침, 계측 예시, APM 모범 사례.
devops
applicationinsights-web-ts
microsoft
브라우저/웹 앱을 Application Insights JavaScript SDK(@microsoft/applicationinsights-web)로 계측합니다. Real User Monitoring(RUM) — 페이지 뷰, 클릭, AJAX/fetch 종속성, 예외, 사용자 지정 이벤트, 백엔드 OpenTelemetry 트레이스와 상관관계가 있는 브라우저 측 GenAI 에이전트 트레이스에 사용합니다. SDK Loader Script 및 npm 설정, 프레임워크 확장(React, React Native, Angular), Click Analytics, 텔레메트리 이니셜라이저, 브라우저에서 생성된 에이전트/도구/모델 스팬에 대한 OTel GenAI 의미론적 규칙을 다룹니다.
devops
azure-ai-anomalydetector-java
microsoft
Azure AI Anomaly Detector SDK for Java로 이상 탐지 애플리케이션을 구축하세요. 단변량/다변량 이상 탐지, 시계열 분석 또는 AI 기반 모니터링을 구현할 때 사용하세요.
development
azure-ai-language-conversations-py
microsoft
azure-ai-language-conversations Python SDK를 사용하여 대화형 언어 이해(CLU)를 구현합니다. ConversationAnalysisClient로 대화 의도와 엔터티를 분석하거나, NLP 기능을 구축하거나, 애플리케이션에 언어 이해를 통합할 때 사용합니다.
development
azure-ai-ml-py
microsoft
Azure Machine Learning SDK v2 for Python. ML 작업 영역, 작업, 모델, 데이터 세트, 컴퓨팅 및 파이프라인에 사용합니다. 트리거: "azure-ai-ml", "MLClient", "workspace", "model registry", "training jobs", "datasets".
development