Find and read logs from Code OSS dev builds. Use when: finding logs, reading log files, debugging Code OSS, checking renderer logs, extension host logs, agent host logs, main process logs, investigating errors in dev builds.
80
100%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
View guide
Passed
No findings from the security scan
Find and display logs from the most recent Code OSS or Agents app dev run.
| App | Default User Data Dir | Logs 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.
ls -lt "$HOME/.vscode-oss-dev/logs" | head -5
# or for a custom user data dir:
ls -lt "<user-data-dir>/logs" | head -5tail for recent entries or rg to filter.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 enabledoutput_ FoldersA 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.
| Investigating... | Check these files |
|---|---|
| App startup / crashes | main.log, window1/renderer.log |
| Extension issues | window1/exthost/exthost.log, window1/exthost/<publisher.ext>/ |
| Copilot / agent issues | agenthost.log, window1/exthost/GitHub.copilot-chat/ |
| Agent host IPC (Agents app) | window1/output_<timestamp>/agenthost.*.log |
| MCP server problems | mcpGateway.log, window1/mcpServer.*.log |
| Terminal problems | terminal.log, ptyhost.log |
| Network / auth issues | network-shared.log, window1/network.log |
| Settings sync | userDataSync.log |
| Agent customizations | 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 -printWhen 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.
src/vs/platform/log/common/log.ts, find isDevConsoleLogForwardingEnabled.Boolean("true") line:
export const isDevConsoleLogForwardingEnabled = false
|| Boolean("true") // done "weirdly" so that a lint warning prevents you from pushing this
;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.
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.console.debug, console.error, console.info, console.log, and console.warn are written through the process log service into the normal log files.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.ILogService for probes that must persist in the log files; native console.log may only appear in DevTools or stdout.window1/ is the first window; multi-window sessions will have window2/, etc.YYYY-MM-DD HH:MM:SS.mmm [level] message.b87c504
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.