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

[kolkov]

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:

• [Bug] Settings file becomes corrupted after update #14672 — Settings file corruption (SyntaxError: Expected double-quoted property name in JSON)
  • This is exactly what happens with concurrent writes without proper locking!
• [Bug] The .claude.json elephant in the room: Is this "vibe coding" in production? #7243 — 8+ months of complaints about .claude.json architecture (no atomic writes, no separation of concerns)

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:

• [Bug] Settings file becomes corrupted after update #14672 — Settings file corruption (JSON parse error) — SAME ROOT CAUSE
• [BUG] Long responses overflow from status bar causing UI rendering issues #14658 — UI rendering issues on Windows
• Fear of updating: When 'vibe coding' meets production stability #14642 — Fear of updating: vibe coding vs stability
• [Bug] The .claude.json elephant in the room: Is this "vibe coding" in production? #7243 — .claude.json architectural issues (8+ months unresolved)

[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

[kolkov]

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.

[kolkov]

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

[kolkov]

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!

• Issue [Bug] Multiple Claude Code instances freeze on macOS due to file locking conflict #13287 reports problems starting with v2.0.59-2.0.60
• Issue [BUG] CRITICAL: Multiple Instances of Claude Code now prevent each other from working #13499 reports regression from v2.0.50 → v2.0.61

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:

• [Bug] Rendering Issue: Large Blank Areas Where Text Should Display #14632 — "Large blank areas where text should display"
• Markdown tables render incorrectly in terminal (broken layout, truncated text) #14641 — "Markdown tables render incorrectly"

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?

[kolkov]

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:

• .claude.json architecture has been broken for 8+ months ([Bug] The .claude.json elephant in the room: Is this "vibe coding" in production? #7243)
• Background agents (v2.0.60) broke multi-instance support — still unfixed after 20+ versions
• No atomic writes, no file locking, no separation of concerns
• Users experience complete system freezes, data loss, JSON corruption ([Bug] Settings file becomes corrupted after update #14672)
• Every new release introduces MORE bugs, not fewer
• There is NO stability whatsoever

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

[kolkov]

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?

[kolkov]

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?