[BUG] /insights fails with EBUSY on Windows — cannot read current session's session-meta file (v2.1.71 regression)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

/insights fails with EBUSY: resource busy or locked on Windows when trying to read the current session's own session-meta JSON file. This is a regression — last successful run was March 4 (pre-v2.1.71); claude.exe binary updated to v2.1.71 on March 6; all attempts since then fail.

The failing file is always the current session's own session-meta UUID. Tested across multiple independent terminals — each new session fails on its own file, with a different UUID each time.

What Should Happen?

/insights should either:

1. Read the current session's data from in-memory state instead of from disk
2. Use a sharing-compatible file open mode (e.g. FILE_SHARE_READ on Windows)
3. Gracefully skip or handle EBUSY on the current session's file and continue processing the remaining files

Error Messages/Logs

Error: EBUSY: resource busy or locked, open 'C:\Users\<user>\.claude\usage-data\session-meta\<current-session-uuid>.json'

No full stack trace is displayed -- only this single-line error. The UUID changes per session (it is always the current session's own file).

Steps to Reproduce

1. Open a new terminal on Windows (no other Claude sessions running)
2. Run claude to start an interactive session
3. Run /insights
4. Observe immediate error: EBUSY: resource busy or locked, open 'C:\Users\<user>\.claude\usage-data\session-meta\<current-session-uuid>.json'

100% reproducible — every new session fails on its own session-meta file.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Pre-2.1.71

Claude Code Version

2.1.71 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

Key Evidence: Lock is intra-process, not OS-level

An external Node.js process can read all 312 session-meta files without any errors:

const fs = require('fs');
const path = require('path');
const dir = path.join(process.env.USERPROFILE, '.claude', 'usage-data', 'session-meta');
const files = fs.readdirSync(dir);
let errors = 0, ok = 0;
for (const f of files) {
  try { JSON.parse(fs.readFileSync(path.join(dir, f), 'utf8')); ok++; }
  catch { errors++; }
}
console.log('OK:', ok, 'Errors:', errors);
// Output: OK: 312 Errors: 0

This proves the file is not locked at the OS level -- it is only inaccessible from within the running Claude process itself.

Suspected Cause

The v2.1.71 changelog includes:

"Improved file operation performance by avoiding reading file contents for existence checks (6 sites)"

One possibility is that the session-meta write path now holds a file descriptor open for the session lifetime. On Windows, a held-open write descriptor can block same-process re-opens -- even for reading. This is speculative based on temporal correlation; not confirmed via source inspection.

Regression Timeline

• March 4: /insights works successfully. report.html and facets/ updated.
• - March 6: claude.exe binary updated to v2.1.71 (file timestamp confirms).
• - - March 8: /insights fails with EBUSY in every session tested.

No other environment changes (OS updates, Node version, hooks, antivirus policy) occurred in this window.

Not Caused by Hooks

Custom hooks installed (PermissionRequest, Stop, Notification, PostToolUse, SessionStart, SessionEnd) were reviewed -- none access usage-data/ or session-meta files.