Bug: IDE lock file deleted in IntelliJ IDEA integrated WSL terminal

Resolved 💬 3 comments Opened Dec 18, 2025 by git-qiaozq Closed Feb 14, 2026

Bug Report: IDE Lock File Deleted When Starting Claude Code in IntelliJ IDEA's Integrated WSL Terminal

Summary

When starting Claude Code in IntelliJ IDEA's integrated WSL terminal, the IDE lock file created by the IDEA Claude Code plugin in Windows is deleted after approximately 3 seconds, preventing the /ide command from discovering the IDE connection.

Environment

  • OS: Windows (with WSL2 Ubuntu)
  • WSL Distribution: Ubuntu
  • IDE: IntelliJ IDEA (with Claude Code plugin installed, IDEA version: 2025.1.3, claude code plugin version: 0.1.14-beta)
  • Claude Code Installation: Installed in WSL via npm global
  • Terminal: IDEA's integrated terminal (configured as wsl -d ubuntu)
  • Claude Code Version: (2.0.72)
  • Node Version: v20.19.5

Problem Description

The Issue

When Claude Code is started in IDEA's integrated WSL terminal, it deletes the Windows-side IDE lock file created by the IDEA plugin, causing /ide command to report "No IDEs found".

Expected Behavior

  • IDEA plugin creates a lock file in C:\Users\<username>\.claude\ide\<pid>.lock
  • Claude Code started in any WSL terminal should be able to discover and connect to IDEA via /ide
  • Lock file should remain intact

Actual Behavior

  • IDEA plugin creates lock file successfully
  • When Claude Code is started in IDEA's integrated terminal (WSL), the lock file is deleted after ~3 seconds
  • /ide command cannot find the IDE
  • The same Claude Code binary works perfectly when started from external terminals (e.g., Xshell)

Reproduction Steps

Test 1: Working Scenario (External Terminal)

  1. Close all Claude Code instances
  2. Open IntelliJ IDEA (Claude Code plugin installed and running)
  3. Verify Windows lock file exists: dir %USERPROFILE%\.claude\ide
  • File exists: <pid>.lock (e.g., 27256.lock)
  1. Open Xshell (or any external WSL terminal)
  2. Navigate to project directory: cd /home/jay/spring
  3. Start Claude Code: claude
  4. Run /ide command
  5. Result: ✅ IDE discovered successfully, lock file remains intact

Test 2: Failing Scenario (IDEA Integrated Terminal)

  1. Close all Claude Code instances
  2. Open IntelliJ IDEA
  3. Verify Windows lock file exists: dir %USERPROFILE%\.claude\ide
  • File exists: 27256.lock
  1. Open IDEA's integrated terminal (WSL)
  2. Working directory is already set to project: /home/jay/spring
  3. Start Claude Code: claude
  4. Wait ~3 seconds after startup completes
  5. Check Windows lock file: dir %USERPROFILE%\.claude\ide
  6. Result: ❌ Lock file deleted, /ide shows no IDEs found

Test 3: Single Instance Verification

To rule out multi-instance conflicts:

  1. Close all Claude Code instances
  2. Open IDEA (lock file created)
  3. Start Claude Code ONLY in IDEA's integrated terminal (no other instances)
  4. Result: ❌ Lock file still gets deleted

Technical Analysis

Lock File Contents

The lock file created by IDEA plugin contains:

{
  "workspaceFolders": ["/home/jay/spring"],
  "pid": 27256,
  "ideName": "IntelliJ IDEA",
  "transport": "ws",
  "runningInWindows": true,
  "authToken": "saOzBd9YrcVxBr6OJUdwZDca9zC0kwOvur2NUnq8oXtDrh6GfctXumsJbbZSi7Hw0WauSOMxfHWU_y8Ekog1NQ"
}

Key fields:

  • runningInWindows: true - Indicates Windows process
  • pid: 27256 - Windows process ID

Root Cause Hypothesis

When Claude Code starts in WSL and validates IDE connections:

  1. It reads lock files to check if the referenced process is still running
  2. For runningInWindows: true lock files, it likely uses ps -p <pid> to verify the process
  3. Problem: ps -p 27256 fails in WSL because 27256 is a Windows process ID
  4. Claude Code incorrectly concludes the lock file is "orphaned" and deletes it
  5. This should be using tasklist.exe for Windows processes instead:

```bash
# In WSL, this fails:
$ ps -p 27256
(no output - process not found)

# But this succeeds:
$ tasklist.exe | grep 27256
idea64.exe 27256 Console 1 2,590,748 K
```

Why External Terminal Works

This is still unclear. Both Xshell and IDEA integrated terminal run in WSL and should have the same process validation issue. The key difference might be:

  • Different environment variables or detection logic
  • Different terminal type identification
  • Some hidden trigger condition specific to IDEA's integrated terminal

Debug Log Analysis

Debug log from IDEA integrated terminal session (with CLAUDE_DEBUG=1) shows:

  • Frequent PowerShell calls to get Windows user profile
  • No explicit log entries about lock file deletion
  • The deletion happens silently without debug output
  • Timing: deletion occurs ~3 seconds after startup completes (not during startup)

Impact

  • Users cannot use /ide command when running Claude Code in IDEA's integrated terminal
  • Forces users to switch to external terminals, reducing integration convenience
  • Workflow disruption for users who prefer integrated terminal experience

Workaround

Use an external WSL terminal (e.g., Windows Terminal, Xshell) to run Claude Code and connect via /ide.

Suggested Fix

  1. When validating lock files with runningInWindows: true, use Windows-appropriate process checking:

``javascript
// Pseudocode
if (lockFile.runningInWindows) {
// Use tasklist.exe or wmic.exe to check Windows process
const result = execSync(
tasklist.exe /FI "PID eq ${lockFile.pid}");
isAlive = result.includes(lockFile.pid.toString());
} else {
// Use ps for Linux processes
isAlive = processExists(lockFile.pid);
}
``

  1. Add debug logging for lock file validation and deletion to help diagnose similar issues
  1. Consider adding a grace period or confirmation before deleting lock files that might be valid

Additional Information

Environment Variables (IDEA Integrated Terminal)

WSL_DISTRO_NAME=Ubuntu
WSL_INTEROP=/run/WSL/524127_interop
TERM=xterm-256color
PWD=/home/jay/spring

No obvious IDEA-specific environment variables detected that would explain the different behavior.

Process Tree

systemd---init-systemd(Ubuntu)---SessionLeader---Relay---bash---claude

---

Please let me know if you need any additional information or testing to help resolve this issue. I'm happy to provide more debug logs or test specific fixes.

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗