Lock file error and agent timeout issues during complex architectural migration

Environment

• Platform (select one):
• [ ] Anthropic API
• [ ] AWS Bedrock
• [ ] Google Vertex AI
• [x] Other: Claude CLI (which uses Anthropic API internally)
• Claude CLI version: 1.0.61
• Operating System: Linux 6.6.87.1-microsoft-standard-WSL2
• Terminal: WSL2

Bug Description

When attempting to orchestrate a complex architectural migration using multiple specialized agents working in parallel, the Claude CLI encountered lock file corruption and internal graceful-fs module failure that prevented the task from completing successfully. This is a CLI tool bug involving the file system abstraction layer and lock file management during intensive parallel operations.

Technical Details

Crash Location: file:///home/user/.nvm/versions/node/v20.18.2/lib/node_modules/@anthropic-ai/claude-code/cli.js:168

Root Cause Analysis:

• graceful-fs module failure during intensive parallel file operations
• File descriptor exhaustion evidenced by EMFILE/ENFILE error handling in stack trace
• Retry queue system overwhelmed before final lock corruption
• Lock file management system unable to recover from compromised state

Stack Trace Context:
The crash occurred within minified/production code showing:

• graceful-fs file system operation wrappers (readFile, writeFile, appendFile, copyFile, readdir, open)
• Lock acquisition/release function failures
• Timeout and retry mechanism exhaustion
• File descriptor limit handling (EMFILE/ENFILE errors)
• Stream operation management (ReadStream/WriteStream)

Steps to Reproduce

1. Launch multiple agents in parallel using the Task tool for a complex, multi-hour architectural migration (7 agents simultaneously)
2. Agents begin working intensively with file system operations
3. System encounters API timeouts and connection errors during parallel execution
4. graceful-fs retry mechanisms become overwhelmed
5. System attempts extensive retries but eventually fails with lock file corruption: [Error: ENOENT: no such file or directory, stat '/home/user/.claude.lock'] { errno: -2, code: 'ECOMPROMISED', syscall: 'stat', path: '/home/user/.claude.lock' }

Expected Behavior

Multiple agents should work in parallel for extended periods (hours) to complete complex architectural tasks without:

• File descriptor exhaustion
• graceful-fs module failure
• Lock file corruption
• Retry queue overflow

Actual Behavior

• Multiple API timeout errors: "API Error (Request timed out.)" with retry attempts
• Connection errors: "API Error (Connection error.) · TypeError (fetch failed)"
• Pre-flight checks exceeded expected duration with warnings about slow API requests
• graceful-fs module retry mechanisms overwhelmed
• Final failure with lock file corruption: ECOMPROMISED error on ~/.claude.lock file
• Process terminated with Node.js error showing extensive minified stack trace

Additional Context

• This occurred during intensive parallel agent operations designed to run autonomously for several hours
• Multiple agents launched simultaneously to work on different aspects of a complex migration
• Error logs show extensive retry attempts across multiple subsystems before final failure
• The critical issue is the CLI's graceful-fs abstraction layer becoming overwhelmed during high-intensity parallel file operations
• Production-minified code makes debugging more challenging

Complete Error Details:

[Error: ENOENT: no such file or directory, stat '/home/user/.claude.lock'] {
  errno: -2,
  code: 'ECOMPROMISED',
  syscall: 'stat',
  path: '/home/user/.claude.lock'
}

Stack Trace Shows:

• graceful-fs module internal failure at cli.js:168
• File system operation wrapper failures
• Retry queue management system breakdown
• Lock file management system corruption
• File descriptor resource exhaustion patterns

This appears to be a resource exhaustion issue in the graceful-fs layer during sustained parallel agent operations, leading to lock file system corruption when the retry mechanisms are overwhelmed.