Repository navigation
When using VSCode in portable mode with the tmp directory enabled, extensions fail to activate properly and get stuck in an activation state. #4433
Description
Describe the bug
On macOS, download vscode and enable portable mode. At the same time, create a temporary tmp file directory in the data directory, then open the vscode and Java project and install the Java plugin. The plugin will always be stuck in active mode, with no error messages or actions.
To Reproduce
Steps to reproduce the behavior:
- Download the VSCode directory installed in portable mode, and create the tmp directory in the data directory of that mode,
- Launch VSCode normally, install the Java plugin, and open the Java project. The plugin will show 'Activated' in the status bar
- But nothing happened, and the project settings kept loading and couldn't be opened.
- The final inspection results showed Sock Unix domain path too long
** log **
!SESSION 2026-06-18 13:27:33.609 -----------------------------------------------
eclipse.buildId=unknown
java.version=21.0.11
java.vendor=Eclipse Adoptium
BootLoader constants: OS=macosx, ARCH=aarch64, WS=cocoa, NL=zh_CN_#Hans
Framework arguments: --pipe=/Users/renjinwei/work/software/JAVA/VScode/code-portable-data/tmp/lsp-f071153a9be153d587c38afa2047.sock
Command-line arguments: -data /Users/renjinwei/work/software/JAVA/VScode/code-portable-data/user-data/User/workspaceStorage/f312aede2c1bb8af530fef927489ae6f/redhat.java/jdt_ws --pipe=/Users/renjinwei/work/software/JAVA/VScode/code-portable-data/tmp/lsp-f071153a9be153d587c38afa2047.sock
!ENTRY org.eclipse.jdt.ls.core 1 0 2026-06-18 13:27:34.543
!MESSAGE class org.eclipse.jdt.ls.core.internal.JavaLanguageServerPlugin is started
!ENTRY org.eclipse.jdt.ls.core 1 0 2026-06-18 13:27:34.564
!MESSAGE Started org.eclipse.buildship.core 15ms
!ENTRY org.eclipse.jdt.ls.core 1 0 2026-06-18 13:27:34.564
!MESSAGE Started org.eclipse.m2e.core 0ms
!ENTRY org.eclipse.jdt.ls.core 4 0 2026-06-18 13:27:34.569
!MESSAGE Unix domain path too long
!STACK 0
java.net.SocketException: Unix domain path too long
[Please attach a sample project reproducing the error]
No need,
Expected behavior
I hope it works properly. If the path is too long, you can use a shorter /tmp path or at least give an error message.
Screenshots
Environment
- Operating System: macos@26
- JDK version: jdk@25
- Visual Studio Code version: code@1.125.1
- Java extension version: 1.55.2026061909
Additional Information
none
Activity
chagong commentedon Jun 23, 2026
I reproduced the root cause from the provided log.
vscode-javausesTransportKind.pipe, and the pipe path is generated byvscode-jsonrpc; in this case portable mode makesos.tmpdir()point tocode-portable-data/tmp, producing a 103-character Unix socket path.That is still too long for OpenJDK on macOS: Java’s Unix-domain socket code effectively allows only 102 bytes (
sizeof(sun_path) - 2), soSocketChannel.connect(...)fails withUnix domain path too long. Latestvscode-languageclient/vscode-jsonrpcimproves the old suffix calculation, but it still uses a Darwin budget of 103, so it does not fully fix this portabletmpcase.The fix should either keep generated macOS pipe paths at
<= 102bytes for Java clients, or makevscode-javafall back tostdio/another transport when the temp path is too long.chagong commentedon Jun 24, 2026
@datho7561 This is a real issue. I created a fix PR at vscode-languageserver side. But at our side do you agree to fall back to stdio as transport layer for JSONRPC if named pipe connection fails?
datho7561 commentedon Jun 24, 2026
I think it's an okay idea to fall back to stdio. The main problem with using stdio was that the JVM itself was sometimes printing strings to stdio, which would interfere with the communication with the language client, and we couldn't find a way to suppress that output. However, from my understanding, this was an edge case; it usually only happened when something was going wrong in the JVM.