Use your IDE

Speedwave runs Claude in an isolated container, away from your editor. The IDE bridge lets Speedwave reach across that boundary and work with the editor open on your machine: opening the files it edits, reading the diagnostics your editor already shows. This is separate from the terminal CLI, which runs Claude from your terminal instead of a chat session.

Speedwave connects to the bridge on its own, without any command in the session. To route it to a real editor, pick one in the Speedwave Health Dashboard. Until you do, the bridge answers requests with empty stub responses and reports that no IDE is connected.

What you need

Open your project in a supported editor, then select that editor in the Health Dashboard. Speedwave remembers the selection and reconnects to it on the next start.

The bridge connects to any editor that writes a Claude Code IDE lock file under ~/.claude/ide/. Speedwave’s code references VS Code (through the Claude Code extension) and Cursor (through its built-in Claude Code integration) by name. Other editors that implement the same lock-file protocol, such as JetBrains IDEs through the Claude Code plugin, can also show up in the dashboard. Speedwave does not keep a fixed editor list; it lists whatever lock files it finds with a live process behind them.

How the connection works

Speedwave runs a proxy between Claude in the container and your editor on the host. Claude sends a request, such as open a file or return the current diagnostics, and Speedwave forwards it to the editor you selected and returns the reply. When no editor is selected, Speedwave answers with stub responses instead of proxying.

To set this up, Speedwave opens a listener on the host and writes a lock file with the connection details for reaching it. That folder is mounted into the container read-only, so Claude can read the connection details but cannot change them.

• A background watchdog checks every five seconds that the lock file still exists, and rewrites it if it was removed. When the bridge itself stops, Speedwave removes the file.
• The Health Dashboard rescans ~/.claude/ide/ on the same five-second cadence, confirms each detected editor’s process and port are still live, and skips the bridge’s own lock file before listing an editor as available.

How the connection stays private

The listener binds to the loopback address 127.0.0.1 only, so nothing on your local network or the wider internet can reach it, only software on your own machine can. When the bridge starts, Speedwave generates a random access token and writes it into the lock file; Claude reads the token and presents it on every request, and Speedwave compares the presented token against the real one in constant time, so the time a check takes never reveals the token.

The lock file holds that token, so Speedwave restricts who can read it: on macOS and Linux the file and its folder are readable only by your own user account (0o600 and 0o700), and on Windows Speedwave applies an owner-only permission to the same effect. Speedwave also rejects any connection that arrives with an Origin header, answering with HTTP 403; Claude Code and the editor extensions never send that header, but web browsers do, so this blocks a web page from reaching the bridge through your browser. See Isolation model for how this fits the container’s broader security boundaries.

When more than one editor is open

The dashboard can detect several editors at once, but Speedwave routes to one at a time, the one you selected. If that editor closes, or its lock file goes away, the bridge shows as not connected until you select an available editor again. For that and other connection problems, see Troubleshooting.