slipstream — The in-memory editing daemon

01 GET STARTED

Two commands to four tools

Install the binary, register it as an MCP server, restart your client. That's it.

install

# macOS (Apple Silicon + Intel) and Linux $ curl -fsSL https://slipstream.sh/install.sh | sh # or from source $ cargo install --git https://github.com/aetherwing-io/slipstream

connect as MCP server

# Claude Code $ claude mcp add slipstream -- slipstream-mcp # or any MCP client — add to your config: "slipstream": { "command": "slipstream-mcp" }

Restart your client. Four tools appear:

Tool	What it does
slipstream	File editing operations. One-shot with files=[...] or session mode. DSL and JSON ops.
slipstream_session	Session lifecycle. open, flush, close, register, unregister.
slipstream_query	Read-only queries. read, status, list, check.
slipstream_help	Reference card with ops format, session actions, query syntax, and common workflows.

macOS + Linux · Works with Claude Code, Cursor, Windsurf, or any MCP-compatible client

02 CAPABILITIES

What one daemon gives your agent

One-Shot

Self-contained edits

files=[...] → ops → flush → done. No session management needed. Open, edit, write, close in a single tool call.

Batch Ops

Multiple edits, one call

Multiple str_replace, read, write, cursor ops in a single tool call. DSL strings or JSON objects — mix freely.

Sessions

Named concurrent sessions

Multiple agents edit different files simultaneously without conflicts. Each session tracks its own buffer state independently.

Conflict Detection

External changes caught

External modifications detected before flush. Force-flush available when you know what you're doing.

Atomic Flush

All or nothing

All edits apply or none do. Writes hit disk only when you say flush=true. Your buffer is your safety net.

DSL + JSON

Two syntaxes, one array

DSL for quick edits (str_replace f.rs old:"foo" new:"bar"), JSON for multi-line content. Both in the same ops array.

03 THE RECEIPTS

Measured, not promised

Traditional file editing vs. slipstream on the same codebase. Same agent. Same task.

Scenario	Reduction	How
Multi-file refactor	18→1 tool calls	One-shot: open, edit, flush, close in a single call
Session editing	0 re-reads	In-memory buffer — no file re-reads between edits
Conflict resolution	0 lost changes	External modification detected before flush

slipstream — one-shot edit

{ "files": ["src/main.rs", "src/lib.rs"], "ops": [ "str_replace src/main.rs old:\"foo\" new:\"bar\"", {"method": "file.str_replace", "path": "src/lib.rs", "old_str": "deprecated()", "new_str": "replacement()"} ], "flush": true } ✓ 2 files opened → 2 edits applied → flushed to disk

Two files, two edits, one tool call. DSL and JSON mixed in the same ops array.

slipstream_session — open + edit + flush

# Open a session → slipstream_session("open src/main.rs src/lib.rs") ✓ Session "default" opened with 2 files # Apply edits → slipstream(ops=["str_replace src/main.rs old:\"v1\" new:\"v2\""]) ✓ 1 edit applied (unflushed) # Flush to disk → slipstream_session("flush") ✓ 1 file written

Session persists between calls. Edit as many times as you need, flush when ready.

slipstream — conflict detected

→ slipstream(flush=true) ⚠ Conflict: src/main.rs modified externally disk: 2024-01-15T10:32:01Z (newer) buffer: 2024-01-15T10:30:45Z Use force=true to overwrite, or re-open to pick up changes

External edits caught before your work overwrites them. No silent data loss.

slipstream_query — check build

→ slipstream_query("check build") Running: cargo build --message-format=json ✓ Build passed (0 errors, 2 warnings) Unflushed edits in session "default": src/main.rs 2 pending ops src/lib.rs 1 pending op

Check your build without flushing. See what's pending before you commit.