claude-code - 💡(How to fix) Fix EBUSY file lock error on Windows when multiple sessions write to .claude.json [1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#46482Fetched 2026-04-11 06:19:08
View on GitHub
Comments
1
Participants
2
Timeline
5
Reactions
0
Author
Timeline (top)
labeled ×3commented ×1cross-referenced ×1

Running multiple Claude Code sessions simultaneously on Windows causes intermittent EBUSY: resource busy or locked errors when writing to ~/.claude.json. This is Windows-specific — macOS and Linux don't exclusively lock files during writes the same way.

Error Message

ERROR EBUSY: resource busy or locked, open 'C:\Users\<user>\.claude.json'

  at writeFileSync (unknown)
  VZ8 (B:/~BUN/root/src/entrypoints/cli.js:135:1271)
  NcK (B:/~BUN/root/src/entrypoints/cli.js:442:23227)
  p6 (B:/~BUN/root/src/entrypoints/cli.js:442:21289)
  <anonymous> (B:/~BUN/root/src/entrypoints/cli.js:8305:475)
  Au (B:/~BUN/root/src/entrypoints/cli.js:492:63164)
  zm8 (B:/~BUN/root/src/entrypoints/cli.js:492:76228)
  dR (B:/~BUN/root/src/entrypoints/cli.js:492:76109)
  zm8 (B:/~BUN/root/src/entrypoints/cli.js:492:77018)
  dR (B:/~BUN/root/src/entrypoints/cli.js:492:76109)

Root Cause

writeFileSync on Windows acquires an exclusive file lock. When two Claude Code processes try to write to the same .claude.json simultaneously, the second process gets EBUSY.

This doesn't happen on macOS/Linux because POSIX file writes don't acquire exclusive locks by default.

Code Example

ERROR EBUSY: resource busy or locked, open 'C:\Users\<user>\.claude.json'

  at writeFileSync (unknown)
  VZ8 (B:/~BUN/root/src/entrypoints/cli.js:135:1271)
  NcK (B:/~BUN/root/src/entrypoints/cli.js:442:23227)
  p6 (B:/~BUN/root/src/entrypoints/cli.js:442:21289)
  <anonymous> (B:/~BUN/root/src/entrypoints/cli.js:8305:475)
  Au (B:/~BUN/root/src/entrypoints/cli.js:492:63164)
  zm8 (B:/~BUN/root/src/entrypoints/cli.js:492:76228)
  dR (B:/~BUN/root/src/entrypoints/cli.js:492:76109)
  zm8 (B:/~BUN/root/src/entrypoints/cli.js:492:77018)
  dR (B:/~BUN/root/src/entrypoints/cli.js:492:76109)

---

function writeFileSyncRetry(path, data, options, retries = 3, delay = 50) {
  for (let i = 0; i < retries; i++) {
    try {
      writeFileSync(path, data, options);
      return;
    } catch (err) {
      if ((err.code === 'EBUSY' || err.code === 'EPERM') && i < retries - 1) {
        const waitUntil = Date.now() + delay * (i + 1);
        while (Date.now() < waitUntil) {} // sync backoff
        continue;
      }
      throw err;
    }
  }
}
RAW_BUFFERClick to expand / collapse

Description

Running multiple Claude Code sessions simultaneously on Windows causes intermittent EBUSY: resource busy or locked errors when writing to ~/.claude.json. This is Windows-specific — macOS and Linux don't exclusively lock files during writes the same way.

Error

ERROR EBUSY: resource busy or locked, open 'C:\Users\<user>\.claude.json'

  at writeFileSync (unknown)
  VZ8 (B:/~BUN/root/src/entrypoints/cli.js:135:1271)
  NcK (B:/~BUN/root/src/entrypoints/cli.js:442:23227)
  p6 (B:/~BUN/root/src/entrypoints/cli.js:442:21289)
  <anonymous> (B:/~BUN/root/src/entrypoints/cli.js:8305:475)
  Au (B:/~BUN/root/src/entrypoints/cli.js:492:63164)
  zm8 (B:/~BUN/root/src/entrypoints/cli.js:492:76228)
  dR (B:/~BUN/root/src/entrypoints/cli.js:492:76109)
  zm8 (B:/~BUN/root/src/entrypoints/cli.js:492:77018)
  dR (B:/~BUN/root/src/entrypoints/cli.js:492:76109)

Steps to Reproduce

  1. Open two Claude Code sessions on Windows (e.g., two terminals, or CLI + desktop app)
  2. Use both sessions actively
  3. The error occurs when both try to write to .claude.json at the same time

Root Cause

writeFileSync on Windows acquires an exclusive file lock. When two Claude Code processes try to write to the same .claude.json simultaneously, the second process gets EBUSY.

This doesn't happen on macOS/Linux because POSIX file writes don't acquire exclusive locks by default.

Suggested Fix

Wrap the writeFileSync call to .claude.json with a retry-on-EBUSY pattern:

function writeFileSyncRetry(path, data, options, retries = 3, delay = 50) {
  for (let i = 0; i < retries; i++) {
    try {
      writeFileSync(path, data, options);
      return;
    } catch (err) {
      if ((err.code === 'EBUSY' || err.code === 'EPERM') && i < retries - 1) {
        const waitUntil = Date.now() + delay * (i + 1);
        while (Date.now() < waitUntil) {} // sync backoff
        continue;
      }
      throw err;
    }
  }
}

Alternatively, use atomic writes (write to a temp file, then rename) which avoids the lock contention entirely.

Environment

  • OS: Windows 11 Pro
  • Claude Code version: 0.9.560
  • Runtime: Bun

extent analysis

TL;DR

Implement a retry mechanism for writeFileSync calls to .claude.json to handle EBUSY errors on Windows.

Guidance

  • Identify all instances of writeFileSync calls to .claude.json and replace them with the suggested writeFileSyncRetry function to implement a retry-on-EBUSY pattern.
  • Consider using atomic writes as an alternative solution to avoid lock contention entirely.
  • Verify the fix by running multiple Claude Code sessions simultaneously and checking for the absence of EBUSY errors.
  • Test the retry mechanism with different retry counts and delay values to find the optimal configuration for your use case.

Example

// Replace writeFileSync with writeFileSyncRetry
writeFileSyncRetry('.claude.json', data, options);

Notes

The suggested fix is specific to Windows and may not be necessary on other platforms. The retry mechanism may introduce additional latency, so it's essential to test and optimize the retry count and delay values.

Recommendation

Apply the workaround by implementing the writeFileSyncRetry function, as it provides a straightforward solution to handle EBUSY errors on Windows without requiring significant changes to the existing codebase.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING