Skip to content

[Bug] Complete system freeze when running 2+ GoLand IDE instances with Claude Code #14674

New issue
New issue
Closed as not planned
Closed as not planned
[Bug] Complete system freeze when running 2+ GoLand IDE instances with Claude Code#14674
Labels
area:corearea:ideautocloseIssue will be closed automaticallybugSomething isn't workinghas reproHas detailed reproduction stepsmemoryplatform:windowsIssue specifically occurs on Windows

Description

@kolkov
kolkov
opened on Dec 19, 2025

Bug Description

Complete system freeze occurs when running 2 or more GoLand IDE instances with Claude Code simultaneously.

UPDATE: Just Reproduced with Detailed Scenario!

What just happened (2025-12-19):

  1. 3 Claude Code instances running in GoLand IDE
  2. Instance 1: Writing this bug report (active, responding)
  3. Instance 2 & 3: Running long tasks — both froze after 2-3 minutes
  4. Instance 1 remained responsive while others were frozen
  5. Attempted to send a comment from Instance 1 to add details to this issue
  6. INSTANT FREEZE — Instance 1 froze immediately, then entire computer froze
  7. Only hard reboot recovered the system

Root Cause Hypothesis: Concurrent File Access

This behavior strongly suggests race condition in .claude.json file access:

  • All instances read/write to the same config file
  • When Instance 1 tried to save/sync while writing the issue comment
  • File lock contention caused deadlock → system freeze

Supporting evidence from related issues:

Symptoms

  • Computer freezes almost completely
  • Only mouse cursor can move (sometimes)
  • Window switching occasionally works but is extremely sluggish
  • Cannot reboot normally — standard shutdown methods don't work
  • Only hard reboot (long press on power button) recovers the system

Environment Info

  • Platform: Windows 10 (win32)
  • Terminal: GoLand IDE (multiple instances)
  • Claude Code Version: 2.0.72
  • Feedback ID: 6dec4a08-1e22-4031-b2ff-5884183aa942

Steps to Reproduce

  1. Open GoLand IDE with Claude Code extension
  2. Open a second GoLand IDE instance with Claude Code
  3. Start tasks in both instances simultaneously
  4. Wait 2-3 minutes — one or both will freeze
  5. Try to interact with the remaining responsive instance
  6. System freezes completely — only mouse moves, no keyboard/window response
  7. Hard reboot required

Expected Behavior

Multiple IDE instances should work without causing system-wide freezes. At minimum:

  • Proper file locking for .claude.json
  • Graceful degradation instead of complete system freeze
  • Per-project or per-instance config separation

The Real Fix Needed

As documented in #7243, the .claude.json architecture is fundamentally broken:

  • No atomic writes → file corruption on concurrent access
  • No file locking → race conditions, deadlocks
  • Everything in one file → massive contention

Proposed solution:

~/.claude/
├── config.json          # Static configuration only (rarely written)
├── mcp_servers.json     # MCP settings
├── sessions/            # Per-session state (isolated)
│   ├── session-{uuid}.json
└── data/
    └── history.db       # SQLite for conversation history (proper locking)

Errors

[]

No errors captured — system freezes before any logs can be collected.

Related Issues:

Activity

  1. github-actions
    added
    bugSomething isn't working
    has reproHas detailed reproduction steps
    platform:windowsIssue specifically occurs on Windows
    area:core
    area:ide
    memory
    on Dec 19, 2025

  2. github-actions commented on Dec 19, 2025

    @github-actions
    github-actionsBot
    on Dec 19, 2025 – with GitHub Actions

    Found 3 possible duplicate issues:

    1. [Bug] Multiple Claude Code instances freeze on macOS due to file locking conflict #13287
    2. [BUG] New Terminal Running Claude Code 2.0.2 Freezes if Another Instance is Already Running in Same Folder on Windows 11 #8699
    3. [BUG] CRITICAL: Multiple Instances of Claude Code now prevent each other from working #13499

    This issue will be automatically closed as a duplicate in 3 days.

    • If your issue is a duplicate, please close it and 👍 the existing issue instead
    • To prevent auto-closure, add a comment or 👎 this comment

    🤖 Generated with Claude Code

  3. kolkov commented on Dec 19, 2025

    @kolkov
    kolkov
    on Dec 19, 2025
    Author

    This is NOT a duplicate — it's a CRITICAL escalation

    The referenced issues (#13287, #8699, #13499) describe Claude Code instances freezing.

    This issue describes something far worse:

    • ❌ Not just Claude Code freezing
    • ❌ Not just the IDE freezing
    • ✅ ENTIRE WINDOWS SYSTEM FREEZES — only mouse cursor moves
    • ✅ ONLY HARD REBOOT RECOVERS — power button required
    • ✅ DETAILED ROOT CAUSE ANALYSIS — concurrent .claude.json access

    Why this matters

    The previous issues are "annoying inconveniences" — you restart Claude Code.

    This issue is a CRITICAL SYSTEM STABILITY BUG — you lose all unsaved work across ALL applications, risk filesystem corruption, and waste 5-10 minutes on each hard reboot.

    New evidence linking issues

    I just found #14672 — Settings file corruption with error:

    SyntaxError: Expected double-quoted property name in JSON at position 1229

    This is EXACTLY what happens when multiple processes write to the same JSON file without proper locking:

    1. Process A starts writing
    2. Process B starts writing
    3. File becomes corrupted
    4. Deadlock or infinite loop trying to parse/write corrupted file
    5. System freeze

    The common root cause

    All these issues (#13287, #8699, #13499, #14672, #14674) stem from the same architectural flaw documented in #7243 for 8+ months:

    • .claude.json stores EVERYTHING (config, history, state, changelog)
    • No atomic writes
    • No file locking
    • No separation of concerns

    Please keep this issue open — it provides critical debugging information and connects the dots between multiple related issues.

    @Anthropic-Team Please acknowledge this systemic problem.

  4. kolkov commented on Dec 19, 2025

    @kolkov
    kolkov
    on Dec 19, 2025
    Author

    Additional data loss evidence

    Just realized another critical point:

    When system freezes, the ENTIRE conversation from session start is LOST.

    Not just the last message — EVERYTHING since launching Claude Code in that session.

    This means:

    • Hours of work context gone
    • All code suggestions lost
    • All debugging progress lost
    • Have to re-explain everything from scratch after reboot

    This is because .claude.json doesn't save incrementally — it appears to batch-write or only save on clean exit. When system freezes and requires hard reboot, there's no clean exit, so nothing gets persisted.

    Yet another reason why SQLite with proper transactions (as proposed in #7243) would solve multiple problems:

    1. Atomic writes → no corruption
    2. Incremental saves → no data loss on crash
    3. Proper locking → no concurrent access issues
    4. WAL mode → even better crash recovery

    Current architecture: single JSON file with batch saves = maximum data loss on any failure

  5. kolkov commented on Dec 19, 2025

    @kolkov
    kolkov
    on Dec 19, 2025
    Author

    CHANGELOG Analysis: Root Cause Found in v2.0.60

    I just analyzed the CHANGELOG.md and found something critical:

    v2.0.60 — The Breaking Change

    - Added background agent support. Agents run in the background while you work

    This is EXACTLY when the multi-instance problems started!

    What the CHANGELOG shows:

    • ✅ v2.0.73: "Fixed race condition that could overwrite text" — UI race condition, NOT file access
    • ✅ v2.0.70: "Improved memory usage by 3x" — good, but doesn't fix concurrent access
    • ❌ NO mention of .claude.json locking fixes
    • ❌ NO mention of atomic writes
    • ❌ NO mention of per-instance config separation

    What's NOT in CHANGELOG (8+ months of #7243):

    • SQLite migration
    • File locking for concurrent access
    • Separation of config/history/state
    • Any architectural improvements to .claude.json

    Meanwhile, what IS being shipped:

    • "Added clickable [Image #N] links"
    • "Improved theme picker UI"
    • "Added alt-y yank-pop to cycle through kill ring history"

    Cosmetic features while critical stability bugs remain unaddressed.

    NEW BUG in v2.0.73: Terminal Output Broken

    Just discovered another regression — terminal output is not rendering properly.

    When Claude Code outputs text to terminal, I see:

    ## 2.0.73
… +498 lines (ctrl+o to expand)

    But the actual content is INVISIBLE. The entire output area is blank/collapsed incorrectly. I can't see what Claude wrote in the terminal!

    This might be related to:

    The "Reduced terminal flickering" fix in v2.0.72 seems to have broken terminal rendering entirely.

    @Anthropic-Team The CHANGELOG proves that background agents (v2.0.60) broke multi-instance support, and no fix has been shipped in 20+ versions. Meanwhile, terminal rendering is now broken too.

    Is anyone actually testing these releases before shipping?

  6. kolkov commented on Dec 19, 2025

    @kolkov
    kolkov
    on Dec 19, 2025
    Author

    Calling all Claude Code contributors

    This issue affects system stability — complete Windows freeze requiring hard reboot. Not just Claude Code crash, but entire OS becomes unresponsive.

    Claude Code Team:
    @bcherny @catherinewu @ant-kurt @ashwin-ant @bogini @fvolcic @whyuan-cc @dhollman @rboyce-ant @dicksontsai @sid374 @ThariqS @ddworken @williamhu99 @ltawfik @chrislloyd @wolffiex

    @bcherny — In your Peterman Pod interview you said:

    "You want maintainable code sometimes. You want to be very thoughtful about every line sometimes."

    Yet:

    The Real Ask: OPEN SOURCE THE CODE

    If Anthropic cannot fix these fundamental issues after 8+ months and 20+ versions, please open source the relevant modules.

    The community is ready to help:

    • We have experienced engineers offering PRs
    • We've done the root cause analysis (concurrent .claude.json access)
    • We've proposed solutions (SQLite, file locking, config separation)
    • We're PAYING CUSTOMERS who depend on this tool

    But we CAN'T help when the code is closed.

    Every release makes things WORSE:

    • v2.0.60: Broke multi-instance
    • v2.0.72-73: Broke terminal rendering
    • v2.0.73: JSON corruption continues
    • Quality is DECLINING, not improving

    Options:

    1. Fix it yourselves — but you haven't in 8+ months
    2. Open source the core — let the community fix what you apparently cannot
    3. Acknowledge the problem — at minimum, communicate with your users

    Silence while shipping broken releases is unacceptable. We're not asking for free support — we're offering FREE ENGINEERING HELP that you're refusing by keeping the code closed.

    Users affected: #13287 #8699 #13499 #14672 #7243 #5024 #1449 #6394

    The pattern is clear: closed source + declining quality + no communication = eroding trust

  7. kolkov commented on Dec 19, 2025

    @kolkov
    kolkov
    on Dec 19, 2025
    Author

    Proposal: Rewrite Claude Code in Go

    Since we're discussing fundamental architecture issues and open-sourcing, let me propose something more radical:

    Rewrite Claude Code in Go.

    Why This Makes Sense

    1. TypeScript itself is being rewritten in Go

    Microsoft announced that TypeScript 7 compiler will be written in Go:

    "The native implementation will drastically improve editor startup, reduce most build times by 10x, and substantially reduce memory usage."
    — Anders Hejlsberg, TypeScript Lead Architect

    If the creators of TypeScript chose Go for their most critical tool, maybe it's time for Anthropic to reconsider too.

    2. Go solves the exact problems Claude Code has:

    Problem in TS/Node Go Solution
    Race conditions in file access Built-in sync primitives, channels
    Memory leaks causing system freeze Efficient GC, predictable memory
    No proper file locking syscall.Flock, atomic operations
    JSON corruption on concurrent writes sync.Mutex, proper concurrency
    Single-threaded event loop bottlenecks Goroutines, true parallelism
    Heavy Node.js runtime Single static binary, no dependencies

    3. Existing Go libraries can accelerate development:

    The Go ecosystem already has production-ready components. Here's what I maintain that could help:

    Note: These libraries were built with significant assistance from Claude Opus 4.5!
    This is why the multi-instance bug is critical for me — I maintain 31+ projects across 12 organizations,
    and I NEED multiple IDE windows with Claude Code running simultaneously to keep them all updated and maintained.
    Your bug literally prevents me from using your best model to build libraries that could help YOU.

    🖥️ Terminal UI & Rendering

    • phoenix-tui ⭐10 — High-performance TUI framework
      • 91.8% test coverage, 29,000 FPS rendering
      • 10x faster than Charm (current industry standard)
    • uniwidth — Unicode width calculation (3.9-46x faster)
    • gosh — Modern cross-platform shell

    ⚡ State & Communication

    • signals — Reactive state management (0.51 ns/op)
    • stream — SSE/WebSocket library (<100μs latency)

    🔍 Code Parsing & Search

    • coregex — High-performance regex engine
      • Up to 263x faster than Go stdlib (case-insensitive patterns)
      • Multi-engine: DFA, NFA, Pike VM
      • SIMD acceleration: AVX2/SSSE3 assembly
      • Zero allocations in hot paths
      • Perfect for code search, syntax highlighting, log parsing

    🧠 AI/ML Infrastructure — Local Inference & Training

    • born — Production ML framework for Go
      • 83.8% coverage, MNIST 98.18% accuracy
      • Neural networks, optimizers, data pipelines
      • Local model inference — embeddings, semantic search
      • Fine-tuning & training — custom models without Python dependency
      • Could enable offline AI features, privacy-first processing

    🎮 GPU Acceleration — Training & Inference at Scale

    • webgpu — Zero-CGO WebGPU bindings
      • Complete WebGPU API, 12 working examples
      • Cross-platform: Windows/Linux/macOS
      • GPU-accelerated training — faster than CPU-only
    • wgpu — Pure Go WebGPU (no FFI)
      • 27K lines, 95% coverage
      • Long-term vision: fully independent GPU stack
      • No Rust/C dependencies — pure Go GPU computing
    • gg — GPU-accelerated 2D graphics
      • Canvas-like API for visualizations
      • Training progress, model architecture visualization

    📊 Scientific Computing & Data Storage

    • hdf5 ⭐12 — Pure Go HDF5 file format
      • 86.1% coverage, approved by HDF Group
      • Model weights storage — industry standard format
      • Large datasets — embeddings, training data
      • Checkpointing — save/resume training

    4. Benefits of Go rewrite:

    • ✅ Single binary — no Node.js runtime, no npm, no dependency hell
    • ✅ True concurrency — goroutines instead of event loop
    • ✅ Memory safety — GC without the JavaScript overhead
    • ✅ Cross-compilation — build for any platform from any platform
    • ✅ Smaller footprint — typical Go CLI is 10-20MB vs Node.js app
    • ✅ GPU acceleration ready — WebGPU bindings for AI features
    • ✅ Local ML capabilities — train and run models without external dependencies
    • ✅ 263x faster regex — for code search and parsing
    • ✅ Better testing — Go's testing culture would catch these bugs

    5. The irony

    Anthropic uses Go extensively internally. Claude's infrastructure runs on Go. Yet the developer tool is written in TypeScript and has fundamental stability issues that Go would solve by design.

    The Vicious Cycle

    1. I use Claude Opus 4.5 to build high-quality Go libraries
    2. These libraries could help improve Claude Code
    3. But Claude Code's multi-instance bug prevents me from maintaining them efficiently
    4. So the very tool that could benefit from my work is blocking that work

    Fix the multi-instance bug, and you unlock a community of developers building tools that could make Claude Code better.

    Realistic Path Forward

    1. Open source current codebase — let community identify all issues
    2. Start Go rewrite — focus on core file handling first
    3. Use existing Go libraries — don't reinvent the wheel
    4. Add local AI capabilities — embeddings, semantic search, eventually local inference
    5. Community contributions — many Go developers would help

    I maintain 31+ Go projects across 12 organizations, including TUI frameworks, ML tools, GPU computing, regex engines, and scientific libraries — all built with Claude Opus 4.5. I'd be happy to contribute to a Go-based Claude Code.

    The bottom line: TypeScript was a reasonable choice in 2024 for rapid prototyping. But Claude Code is now a critical tool used by thousands of developers. It deserves production-grade engineering — and that means Go.

    /cc @bcherny @catherinewu — Would Anthropic consider this?

  8. kolkov commented on Dec 19, 2025

    @kolkov
    kolkov
    on Dec 19, 2025
    Author

    Competition is Coming — Act Now or Lose the Market

    One more critical point:

    DeepSeek is releasing their own AI agent by end of 2025

    According to Bloomberg:

    DeepSeek is preparing to release a fully autonomous AI agent by the end of 2025 to compete with US rivals like OpenAI.

    DeepSeek's recent releases:

    • V3.1-Terminus — 40%+ improvement on SWE-bench, enhanced terminal operations
    • V3.2 — "Reasoning-first models built for agents", 1,800+ environments, 85k+ complex instructions
    • R1-0528 — System prompts, JSON output, function calling for agentic use cases

    And here's the kicker: DeepSeek open-sources their models.

    The Competitive Landscape

    Tool Status Open Source
    Claude Code Broken, 8+ month critical bugs ❌ Closed
    DeepSeek Agent Coming end 2025 ✅ Yes
    Cursor/Windsurf Working alternatives Partial
    Community projects nano-claude-code etc. ✅ Yes

    Why This Matters for Anthropic

    1. Users are already leaving — I'm switching to my own Go agent with Anthropic API
    2. Trust is eroding — every crash, every data loss, every ignored issue
    3. Competition will be fierce — DeepSeek's agent will likely be more stable AND open source
    4. First-mover advantage is fading — Claude Code was innovative, but now it's becoming a liability

    The Market Will Fix This

    If Anthropic won't:

    • Fix the stability issues
    • Open source the code
    • Or even communicate with users

    Then the market will simply move to alternatives. DeepSeek, Cursor, Windsurf, or community-built tools.

    The question isn't IF Claude Code will be replaced — it's WHEN.

    Unless Anthropic acts now:

    1. Acknowledge the problems
    2. Commit to fixes with timeline
    3. Open source to accelerate development
    4. Or consider a Go rewrite for long-term stability

    Time is running out. DeepSeek's agent drops in weeks, not months.

    @bcherny @catherinewu @Anthropic-Team — The window to lead in AI coding tools is closing. What's your move?

  9. github-actions commented on Jan 20, 2026

    @github-actions
    github-actionsBot
    on Jan 20, 2026 – with GitHub Actions

    This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.

  10. github-actions
    added
    autocloseIssue will be closed automatically
    on Jan 20, 2026

  11. github-actions commented on Feb 14, 2026

    @github-actions
    github-actionsBot
    on Feb 14, 2026 – with GitHub Actions

    Closing for now — inactive for too long. Please open a new issue if this is still relevant.

  12. github-actions
    closed this as not plannedon Feb 14, 2026

  13. github-actions commented on Feb 23, 2026

    @github-actions
    github-actionsBot
    on Feb 23, 2026 – with GitHub Actions

    This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.

  14. github-actions
    locked as resolved and limited conversation to collaborators on Feb 23, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area:corearea:ideautocloseIssue will be closed automaticallybugSomething isn't workinghas reproHas detailed reproduction stepsmemoryplatform:windowsIssue specifically occurs on Windows

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions