- Deployment: reject `..` and `/` in remote names and sync paths, keep
excluded paths root-relative, never delete a mapping's remote root,
apply excludes to Sync steps
- SSH: connect per configuration so an unreachable host doesn't block
others; `--` before the host in ssh arguments; read timeout on askpass
- Run targets: export the environment for shell command lines; map the
project folder only as a whole path
- Remote development: use the server's resolved project root; give
streaming channels connection-wide ids; per-install `.part` files;
probe output between markers; require the server's SHA-256; unique
download staging folders; stop runs, terminals and language servers
when the server exits
- JSON-RPC: deliver a response after the notifications sent before it
- Release: build the aarch64 musl server with musl-gcc
SSH (new crate ide-ssh)
- Shared SSH configurations (Settings › Tools › SSH Configurations) used by
data source tunnels, deployment servers, run targets and terminals.
- Sessions with password, key pair or OpenSSH config + agent authentication,
ProxyJump, known-hosts checks with trust prompts, saved secrets.
- Askpass: credential prompts of `ssh` / `git` child processes shown in the IDE.
- Tools › Start SSH Session opens a terminal tab for a configuration.
- The database SSH tunnel moves here and can use a shared configuration.
Deployment (new crate ide-remote)
- Settings › Build › Deployment: SFTP servers, path mappings, excludes,
automatic upload on save.
- Upload / download / delete / sync with the server, Tools › Deployment
menu, Remote Host tool window for browsing and editing remote files.
Run targets
- Settings › Build › Run Targets: run configurations can run on an SSH host
("Run on"), with project sync before the run and remote interpreters.
Remote development
- New crate ide-host: the backend (projects, documents, LSP, VCS, search,
terminals, runs, debugger, tools, settings) shared by the desktop shell and
`openidea-server`, a headless server speaking JSON-RPC over stdio.
- File › Remote Development… connects to an SSH host, installs the server
(per-build folder, streamed gzip upload; the release build is downloaded
when there is none locally) and opens a remote folder in the window.
- The window routes the commands the server answers to it; streaming
channels and events are forwarded. The server takes the login shell's PATH.
Adds GDScript, Godot resource and shader file types with tree-sitter highlighting, the GDScript language server over TCP (a headless Godot editor started on demand), "Godot Project" / current-scene run configurations, and debugging through Godot's debug adapter.
Breakpoints set through symlinked paths (/tmp, /var on macOS) were reported verified but never hit; the adapter now sends resolved paths and maps stack frames back to the paths the IDE opened. The duplicate exit event Godot sends after disconnect is ignored.
Fixes#68
Claude-Session: https://claude.ai/code/session_01VUYsdXA2nkF5v6zsC93dpn
Root cause: the IDE only detected installed JDKs and had no way to get one, so any launch needing a newer JDK than the machine has (latest jdtls needs JDK 25) dead-ended in an error.
Fix: IDEA-style Download JDK (Eclipse Temurin via the Adoptium API, sha256-verified, reusing ide-tools' download/verify code; Windows zip, Linux tar.gz, macOS Contents/Home) into <app-data>/tools/jdks, registered with JDK discovery and rescanned after each download. "Download JDK…" in the Project SDK and Language Server JDK pickers; a one-click `java.downloadJdk` "Download JDK N" on "needs JDK N" errors, which also repoints a too-old language server JDK and restarts jdtls.
Siblings: language server status popup, jdtls launch notification, run console classpath error, debug launch, run configurations without a JDK ≥ the module's Java version, Maven/Gradle sync failures, single-file Java run without `java` on PATH.
Verified in the app on macOS: vendor/version/location queries, the Download JDK dialog from the Language Server JDK picker, a real Temurin 25.0.5 download that runs. Not verified on Windows/Linux.
Fixes#49https://claude.ai/code/session_01VUYsdXA2nkF5v6zsC93dpn
Root cause: the tools dir installed typescript@latest, now TypeScript 7 (native port, no typescript.js/tsserver.js/ts.server), so @vue/language-server 3 crashed on ts.server.protocol and restarted forever; Volar 3 hybrid mode also needs tsserver/request forwarding, which we never answered.
Fix: pin TS-as-library servers to typescript@<7 and keep shared deps on uninstall; pick a usable tsdk (setting / bundled / project, --tsdk); bridge tsserver/request to vtsls with @vue/typescript-plugin (null when vtsls is absent); answer workspace/configuration for section ""; stop restarting after 3 consecutive early crashes (IDEA); crash summary starts at the exception line.
Siblings covered: typescript-language-server and svelte-language-server (same TS 7 break), vtsls config, install hints in language TOMLs.
Verified: scoped cargo tests, real-server tests (vue-language-server 3.3.13 + vtsls), in-app on macOS (server running, no crash loop). Not verified on Windows.
Claude-Session: https://claude.ai/code/session_01VUYsdXA2nkF5v6zsC93dpn
Release builds use the GUI subsystem, so a console child spawned without
CREATE_NO_WINDOW gets its own console window. git, gh, docker, builds and
run configurations already set the flag; language servers, SDK and tool
probes, debug adapters, tool downloads, coverage export and perf did not.
Add ide_core::process::no_window and use it at every remaining spawn.
Fixes#16
Release downloads: buf, clojure-lsp, texlab, neocmakelsp, LemMinX, Perl
Navigator, kotlin-language-server, kotlin-debug-adapter and netcoredbg;
Open VSX: bash-debug and php-debug (run through node). Two new methods:
`gem` (ruby-lsp, solargraph), installed into the tool's folder and
launched with GEM_HOME, and `dotnet tool` (csharp-ls, fsautocomplete),
launched with DOTNET_ROOT so a Homebrew / user-local .NET is found.
Tools declare the runtime they need (Java, Node.js, Perl).
Each was installed from its real source and started on macOS arm64.
Claude-Session: https://claude.ai/code/session_01B65qLEKnkeYTGdbwhLpjCu
ElixirLS ships one platform-independent zip of launcher scripts that
build the server with the project's Elixir / OTP on first start. Both
the language server and the debug adapter are installed from it, each
linked to its own launcher (language_server / debug_adapter).
Tools can now declare runtimes they need on PATH; Install stays
disabled with the reason ("Elixir is required") until they are found.
The Elixir debug adapter is renamed elixir-ls-debugger so it no longer
shares the server's tool name.
Claude-Session: https://claude.ai/code/session_01B65qLEKnkeYTGdbwhLpjCu
Servers and debug adapters could only be found on PATH or in the IDE's
tools folder; the only way to pick another executable (a version that
matches the project's Elixir/OTP, a local build) was an undocumented
languages/*.toml override. `tools.<command>.path` now names the
executable to launch: language servers (configure_server, restarted on
change), debug sessions and the tool list honour it, the latter
reporting a Custom status with its version or why the path is unusable.
The Language Servers page is laid out like Plugins: a compact list
grouped by availability on the left, the selected tool's command, path,
location, version, install actions and hints on the right.
A debugger named like its language server (ElixirLS's elixir-ls /
elixir-ls-debugger) was folded into the server's row and never listed;
it now gets a row of its own.
Claude-Session: https://claude.ai/code/session_01B65qLEKnkeYTGdbwhLpjCu
* fix(java): Run jdtls with a Lombok agent and show build errors at launch
jdtls compiles with ECJ, which only generates Lombok members when the
server JVM runs -javaagent:lombok.jar. Nothing put it there, so @Data /
@Setter classes lost their accessors and Run launched stale classes
with "Unresolved compilation problem" stubs and no explanation.
- Projects whose build files mention Lombok get the newest jar: the
IDE-managed one (new "Lombok (jdtls agent)" tool, latest release from
Maven Central), else ~/.m2 (incl. settings.xml localRepository) or the
Gradle cache. Each agent gets its own jdtls workspace so everything is
rebuilt with it.
- Settings › Languages & Frameworks › Java › JVM options
(java.jdt.ls.vmargs); a Lombok agent there wins.
- Run (and Debug, as a notification) list the first compile errors when
the build has errors, plus a hint when Lombok is missing or older than
1.18.34.
Fixes#3
* fix(java): Base the Lombok hint on the agent jdtls actually runs
A Lombok agent in Settings › Java › JVM options wins over the managed
and cached jars, but the launch hint still looked only at those: with
no cached jar it said Lombok was missing, and with an old cached one it
blamed that version although jdtls ran the user's. The hint and the
startup warning now use the user's agent (version from its file name).
l0ng-ai