[BUG] Linux/KDE/Wayland: Starting claude from VS Code integrated terminal spawns 2 extra VS Code windows
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported for Linux/Wayland yet
- [x] This is a single bug report
- [x] I am using the latest version of Claude Code
Discovery
This issue was identified and analyzed by Claude Sonnet 4.6 (claude-sonnet-4-6) running as Claude Code itself, during a debugging session in the affected environment.
Related Issues
This is the Linux/Wayland equivalent of the Windows bug fixed in v2.1.70:
- #30975 — Windows: 3 empty VS Code windows on startup from integrated terminal
- #31080 — duplicate
- #31280 — duplicate
- #32705 — duplicate (with root cause analysis)
The Windows fix addressed the issue for non-Linux platforms. The Linux/Wayland case was never addressed.
What's Wrong?
Starting claude from VS Code's integrated terminal on KDE/Wayland causes 2 extra VS Code windows to open on every startup.
Root Cause (based on v2.1.88 decompiled source — please verify against v2.1.150)
getInstallationEnv() in src/utils/ide.ts clears DISPLAY='' on Linux to prevent the GUI from launching, but does not clear WAYLAND_DISPLAY. On a Wayland session, Electron ignores DISPLAY and uses WAYLAND_DISPLAY to open a window.
// src/utils/ide.ts
function getInstallationEnv() {
if (getPlatform() === 'linux') {
return {
...process.env,
DISPLAY: '', // ← clears X11 only
// WAYLAND_DISPLAY not cleared — Electron still opens on Wayland
}
}
return undefined
}
Each of the following calls spawns a new VS Code window via Wayland:
code --list-extensionscode --list-extensions --show-versionscode --force --install-extension anthropic.claude-code(triggered every startup because installed extension version < CLI version)
Proposed Fix
Either clear WAYLAND_DISPLAY alongside DISPLAY, or apply the same ELECTRON_RUN_AS_NODE=1 fix used for Windows to Linux as well:
function getInstallationEnv() {
if (getPlatform() === 'linux') {
return {
...process.env,
DISPLAY: '',
WAYLAND_DISPLAY: '', // add this
ELECTRON_RUN_AS_NODE: '1', // or this (same fix as Windows)
}
}
return { ...process.env, ELECTRON_RUN_AS_NODE: '1' }
}
Steps to Reproduce
- KDE Plasma on Wayland (Fedora or similar)
- Open VS Code
- Open VS Code's integrated terminal
- Run
claudein any project directory - Observe: 2 extra VS Code windows appear
Environment
- OS: Fedora / KDE Plasma / Wayland (
WAYLAND_DISPLAY=wayland-0,DISPLAY=:0) - Claude Code CLI: 2.1.150
- VS Code extension: 2.1.145
- Terminal detection:
TERM_PROGRAM=vscode→isSupportedTerminal()returns true → auto-install triggers
Evidence
VS Code log directory shows rapid consecutive empty sessions on every claude startup:
~/.config/Code/logs/20260524T132012/ (empty)
~/.config/Code/logs/20260524T132013/ (empty)
~/.config/Code/logs/20260524T132015/ (empty)
Pattern repeated multiple times, each cluster corresponding to a claude startup.
4 Comments
Correction / Caveat on Source Analysis
The source code analysis in this report was based on decompiled v2.1.88 source code (not the current v2.1.150). The internal implementation of
getInstallationEnv()may have changed in the 62 versions between 2.1.88 and 2.1.150.The observed behavior and environment facts remain accurate:
TERM_PROGRAM=vscode,WAYLAND_DISPLAY=wayland-0,DISPLAY=:0claudefrom VS Code's integrated terminal on KDE/Wayland (v2.1.150) spawns 2 extra VS Code windowsclaudestartupThe root cause hypothesis (DISPLAY cleared but WAYLAND_DISPLAY not cleared) is based on older source — please verify against the actual v2.1.150 implementation.
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
👎 Not a duplicate.
The linked issues (#30975, #31080, #32705) are all Windows-specific and were fixed in v2.1.70 by adding
ELECTRON_RUN_AS_NODE=1for non-Linux platforms.This issue is specifically about Linux/KDE/Wayland — where the existing Linux fix (
DISPLAY='') is ineffective because Wayland sessions useWAYLAND_DISPLAY, notDISPLAY. This case was explicitly excluded from the v2.1.70 fix and has never been addressed.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.