Preflight Checklist
What's Wrong?
When Claude Code CLI (claude.exe) is running, Claude Desktop cannot launch. The Desktop app detects the CLI process as an existing instance and exits immediately with:
Not main instance, returning early from app ready
This occurs because Claude Code CLI and Claude Desktop share the same Electron single-instance lock (same executable name / app ID). The Desktop's requestSingleInstanceLock() fails when CLI processes are already running.
Root Cause
Claude Code CLI spawns multiple claude.exe processes. When Claude Desktop subsequently starts, it checks for an existing instance lock and finds one held by the CLI processes. Since Desktop enforces single-instance mode, it immediately exits without rendering any window.
The launch order matters:
| Order |
Result |
| Desktop first, then Code |
Works fine (Desktop holds the lock first) |
| Code first, then Desktop |
Desktop fails to launch (Code holds the lock) |
Steps to Reproduce
- Open a terminal and start Claude Code CLI (
claude)
- Verify multiple
claude.exe processes are visible in Task Manager
- Attempt to launch Claude Desktop from the Start menu
- Result: Desktop does not open. No window appears. No error dialog.
- Check
main.log — the last line reads: Not main instance, returning early from app ready
What Should Happen?
Claude Desktop and Claude Code CLI should be able to run simultaneously regardless of launch order. They are separate products with different use cases and should use distinct app IDs / instance locks.
Workaround
- Kill all Claude processes in Task Manager (including Claude Code)
- Launch Claude Desktop first
- Then start Claude Code CLI
Related Issues
Environment
- Claude Desktop Version: 1.1.4173
- Claude Code CLI Version: Latest (installed via npm)
- OS: Windows 11 Pro
- Arch: arm64
- Shell: Git Bash (also reproducible from PowerShell)
Suggested Fix
Use distinct Electron app IDs or separate instance lock namespaces for Claude Desktop vs Claude Code CLI, so that requestSingleInstanceLock() in Desktop does not conflict with CLI processes.
Claude Model
Opus
Is this a regression?
Unknown — may have existed since Claude Code CLI was first released
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
Bash
Preflight Checklist
What's Wrong?
When Claude Code CLI (
claude.exe) is running, Claude Desktop cannot launch. The Desktop app detects the CLI process as an existing instance and exits immediately with:This occurs because Claude Code CLI and Claude Desktop share the same Electron single-instance lock (same executable name / app ID). The Desktop's
requestSingleInstanceLock()fails when CLI processes are already running.Root Cause
Claude Code CLI spawns multiple
claude.exeprocesses. When Claude Desktop subsequently starts, it checks for an existing instance lock and finds one held by the CLI processes. Since Desktop enforces single-instance mode, it immediately exits without rendering any window.The launch order matters:
Steps to Reproduce
claude)claude.exeprocesses are visible in Task Managermain.log— the last line reads:Not main instance, returning early from app readyWhat Should Happen?
Claude Desktop and Claude Code CLI should be able to run simultaneously regardless of launch order. They are separate products with different use cases and should use distinct app IDs / instance locks.
Workaround
Related Issues
claudecommand via PATH priority (different but related packaging conflict)Environment
Suggested Fix
Use distinct Electron app IDs or separate instance lock namespaces for Claude Desktop vs Claude Code CLI, so that
requestSingleInstanceLock()in Desktop does not conflict with CLI processes.Claude Model
Opus
Is this a regression?
Unknown — may have existed since Claude Code CLI was first released
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
Bash