VSCode extension: SessionStart hook receives source='startup' after /clear instead of 'clear'

Summary

When running Claude Code inside the official VSCode extension, the SessionStart hook receives source="startup" even after the user issues /clear. The documented behavior (and what I observe in MINGW64 terminal) is that source="clear" should be sent after /clear.

This makes it impossible for hooks to distinguish between a genuine new session and a session that follows /clear, which matters for any hook that needs to decide whether to restore / inherit state from the previous session.

Environment

• OS: Windows 11 Pro (10.0.26200)
• Claude Code VSCode extension: anthropic.claude-code v2.1.112 (also tested v2.1.92 — same behavior)
• Terminal: VSCode integrated terminal (extension's bundled claude.exe, path: ~/.vscode/extensions/anthropic.claude-code-2.1.112-win32-x64/resources/native-binary/claude.exe)
• Node.js hook runtime: v22.5+

Reproduction

1. Configure a SessionStart hook in ~/.claude/settings.json:

``json
{
"hooks": {
"SessionStart": [
{ "hooks": [{ "command": "node /path/to/probe.mjs" }] }
]
}
}
``

1. probe.mjs appends the stdin payload to a log file:

``js
import { appendFileSync } from 'node:fs';
let raw = '';
process.stdin.on('data', (c) => { raw += c; });
process.stdin.on('end', () => {
const p = JSON.parse(raw);
appendFileSync('/tmp/probe.log', JSON.stringify({
ts: new Date().toISOString(),
source: p.source,
session_id: p.session_id,
}) + '\n');
process.exit(0);
});
``

1. Open VSCode, start a Claude Code session, issue /clear, repeat.

Observed

30 consecutive SessionStart firings inside the VSCode extension:

| source | count |
|-----------|-------|
| startup | 29 |
| resume | 1 |
| clear | 0 |

The single resume came from a VSCode restart. /clear always produced startup.

Expected

Per the official hooks docs and observations from MINGW64 / bash terminals, /clear should send source="clear" so that hooks can distinguish it from a genuine new session (startup) or a resumed one (resume).

Impact

Third-party hooks that need to inherit or migrate session-scoped state across /clear boundaries cannot rely on source and must fall back to time-based heuristics. For context: we maintain a hook plugin that carries conversation memory across /clear and had to implement a 30-minute updated_at gap heuristic as a workaround.

Additional notes

• Happy to provide the full probe log (30 entries) if helpful.
• Did not test on macOS or Linux VSCode; this report is Windows-specific but the bundled extension binary is where the discrepancy lives.