[BUG] Claude SDK: Critical 65+ second delay on first query execution in Node.js/TypeScript environments

Environment

• Platform (select one):
• [ ] Anthropic API
• [ ] AWS Bedrock
• [ ] Google Vertex AI
• [x] Other: Claude Code SDK (@anthropic-ai/claude-code)
• Claude CLI version: N/A (using @anthropic-ai/claude-code@1.0.61)
• Operating System: macOS (Darwin 24.5.0) - issue appears platform-independent
• Terminal: Any (tested with various Node.js environments)

## Bug Description
The Claude SDK (@anthropic-ai/claude-code) exhibits a critical performance regression causing 65+ second delays on the first query execution in Node.js/TypeScript environments. The delay occurs specifically at the first iterator.next() call when using the standard async iteration pattern. This issue persists across multiple SDK versions (tested v1.0.54
and v1.0.61) and makes real-time applications unusable.

## Steps to Reproduce

1. Create a Node.js/TypeScript project with ES Modules enabled ("type": "module" in package.json)
2. Install the Claude SDK: npm install @anthropic-ai/claude-code@1.0.61
3. Use dynamic import to load the SDK: const sdk = await eval("import('@anthropic-ai/claude-code')")
4. Create a query with standard options: const queryIterable = sdk.query({ prompt: "Hello", options: { maxTurns: 10, allowedTools: [] } })
5. Start async iteration: for await (const message of queryIterable) { console.log(message); }
6. Observe that the first message takes 65+ seconds to arrive

## Expected Behavior

• SDK initialization: < 500ms
• Time to first message: < 2000ms
• Smooth streaming responses without delays
• Consistent performance across multiple queries

## Actual Behavior
Performance Results:

• SDK import: 3ms (fast ✅)
• Async iterable creation: 2ms (fast ✅)
• Iterator creation: 0ms (fast ✅)
• First iterator.next() call: 65,356ms (65+ seconds) ❌
• Subsequent messages: 1-3 seconds (acceptable)
• Total query time: 67,686ms

Version Comparison:

• v1.0.54: 65,356ms delay
• v1.0.61: 65,578ms delay
• Issue persists across versions with virtually identical timing

Blocking Characteristics:

• Occurs on every fresh SDK instance
• One-time penalty per application session
• No observable network activity during delay
• Minimal CPU/memory usage during blocking period
• Subsequent queries in same session are significantly faster

## Additional Context

Reproducible Test Case:
I've created a comprehensive diagnostic tool that consistently reproduces this issue:
```bash
# Available as standalone test project
npm install
npm run test
OR
npm run dev # for interactive testing
# Results: 100% reproducible across multiple runs

[testClaude.zip](https://github.com/user-attachments/files/21477617/testClaude.zip)

  Technical Analysis:
  - Issue occurs during internal SDK initialization deferred until first query
  - The 65-second delay suggests synchronous operation blocking async context
  - Problem affects all Node.js/TypeScript applications using standard async iteration
  - SDK import and setup phases complete quickly - blocking is internal to first execution

  Critical Impact:
  - Severity: Critical - blocks real-time application development
  - User Experience: Makes interactive AI features completely unusable
  - Development: Forces 65+ second wait times for any first interaction
  - Scope: Affects all Node.js/TypeScript applications using the Claude SDK

  Current Workaround:
None

  Evidence Available:
  - Complete test project with millisecond-precision timing analysis
  - Performance logs showing exact blocking points in code execution
  - Version comparison data across multiple SDK releases
  - Reproducible test cases ready for debugging by SDK team

  This represents a critical usability regression that requires immediate investigation, as it makes the Claude SDK impractical for any real-time or interactive application development.