Claude Process List

A VSCode extension that surfaces the processes Claude Code spawns while it's running in your editor — the claude instance(s), the shells launched for Bash tool calls, and anything those shells spawn in turn.

What this extension does not do

It does not, and cannot, intercept process output. The actual stdout/stderr of a Claude-spawned shell never reaches this extension. Claude Code spawns those shells with anonymous stdio pipes whose read ends live inside the claude process's memory; from a sibling extension, pulling that data would require duplicating handles out of claude (which would race Claude's reads — every byte we read is a byte Claude doesn't see), DLL injection, or an undocumented IPC. None of those are appropriate for a polite extension to do.

The chat itself (and the BashOutput tool) is the only place the actual command output shows up. This extension shows you that the processes exist, what their hierarchy looks like, how long they've been running, and how much CPU/RAM they're using — nothing more. The "kill" button works because killing only requires the PID, not pipe access.

The clean fix is upstream: Anthropic exposing tool output to the IDE, or routing Bash tools through vscode.window.createTerminal so the output lands in VSCode's terminal panel natively.

What you get

A single webview in its own activity-bar container renders three layers:

• claude as a thin chip at the top (PID, uptime, CPU%, RAM). Separated by a divider; never shows the long claude command line.
• Intermediate wrappers (shells whose only role is to host another process) as compact single-line rows, just name · pid plus uptime and RAM.
• Leaves — the actual commands you care about — as full cards with the command line shown prominently in monospace.

Each row has an inline kill button (modal confirmation). Click a PID to copy it; click a command line to copy it. Click the disclosure triangle (▶/▼) on any node with children to collapse/expand its subtree.

Why

Claude Code in VSCode does not route its Bash tool calls through vscode.window.createTerminal, so the resulting shells never appear in VSCode's terminal panel — they're invisible from the editor. This extension at least makes their existence, hierarchy, and resource usage visible.

Install / develop

npm install
npx tsc -p ./

Then open this folder in VSCode and press F5. An Extension Development Host window opens with the extension loaded; click the "Claude Processes" icon in the activity bar.

The bundled launch config disables SonarLint in the dev host (it errors out when its database is locked by your main VSCode). Adjust .vscode/launch.json if you don't have SonarLint installed or want it on.

Settings

How "Claude scope" is determined

Both Claude Code and this extension run inside VSCode's shared extension host. From this extension, process.pid is that host's PID. So:

1. We list every process on the system (Windows: Get-CimInstance Win32_Process via PowerShell; Linux/macOS: ps -axww).
2. We walk descendants from our own PID, only following the claude binary (claude.exe on Windows, claude on Linux/macOS — both match the same regex).
3. The helper subprocess this extension itself spawns to gather the snapshot is excluded by PID so it never shows up in the tree.

Platform support

Tested on Windows. Linux/macOS support reuses the existing ps-based path with extended fields (pid,ppid,rss,etime,time,comm,args) and per-platform parsing for the time column (Linux's HH:MM:SS vs macOS's M:SS.cs). A few caveats worth knowing:

• Process names with embedded whitespace (rare on Linux/macOS — comm is typically space-free) won't parse cleanly with the column-based regex. They get dropped from the list.
• ps is invoked with BSD-style flags (-axww); both procps-ng (Linux) and BSD ps (macOS) accept this combination.
• If the Claude Code distribution on your platform ships as a node-launched script rather than a native claude binary, the parent process will be node, not claude. Switch claudeProcessList.scope to extension-host to see the full extension-host descendant tree in that case.

Metrics

• Uptime ticks every second client-side, computed from process start time.
• CPU% is the delta of cumulative kernel+user CPU time between two consecutive snapshots, divided by wall-clock delta and normalized by core count, so 100% means "saturating the whole machine," not "saturating one core." First snapshot has no baseline so CPU is blank for one cycle.
• RAM is the working-set / RSS size (what Task Manager calls "Memory"), formatted in adaptive units (KB/MB/GB).

Project layout

src/
  extension.ts     — activation, message dispatch, auto-refresh
  processUtils.ts  — OS process enumeration + scope/age/exclude filters
  processView.ts   — ClaudeScopeStore (snapshot + CPU-delta tracking)
  webviewView.ts   — webview HTML/CSS/JS and the data-flattening for it
  formatting.ts    — uptime, byte, percent, and shell-command summarization helpers