v0.1.7

Tempest v0.1.7

The Canvas release. A conversation is a line — one message after another, older thinking scrolling out of reach. But engineering work isn't a line. It's research over here, a decision over there, three agents running against different branches, and the connections between them. This release turns the single Chat tab into Threads: a spatial canvas where thinking, discussion, and agent-launching all live as nodes you can see at once.

What's in this release

Threads — The Canvas

The linear Chat tab is gone. In its place is Threads, a node-based canvas (built on React Flow) listed per project in the sidebar. One canvas is one conversation-space; you can keep as many as you like. Each opens as its own tab and remembers its camera, its nodes, and their positions.

Four node types ship in v1:

Node	What it is
Chat	An AI conversation — the old Chat, now one node among many. BYOK streaming, provider/model picker, a context-usage ring, tool-call and agent-proposal cards.
Text	A free-form markdown note with live preview, resizable and auto-growing.
Agent	A running CLI agent, bound to a git branch.
Terminal	A plain shell, bound to a git branch.

Git context is a tool, not a silent prepend. The old Chat quietly stuffed your branch, commits, and status into every message. A chat node instead exposes run_git_status / run_git_log as tools the model calls when it actually needs them — which keeps a canvas honest when it spans several branches and nothing is implicitly "the branch."

A canvas names itself. A new thread opens empty and titled "New thread." The first message you type into its first chat node renames the canvas — the tab and sidebar row follow — unless you've already named it yourself.

Agent & Terminal Nodes — Sessions That Live on the Canvas

An agent or terminal node is a real PTY session whose only home is the node. It has no tab-bar entry — it doesn't crowd your tabs, doesn't appear in the sidebar session list, and is skipped by the startup tab-restore sweep. Delete the node and its session is torn down (PTY killed, row dropped) so nothing leaks. Reopen the canvas later and the session is resumed lazily, right where it was.

"Run in:" — branch binding at launch. Every agent/terminal node picks where it runs: the project root, an existing worktree, or New worktree… typed inline (which reuses the sidebar's worktree-creation path, including the setup hook below). The choice is persisted, and a restart lands the session back in the right worktree with no extra work.

Launch an agent from a chat. The carried-over headline of the old Chat — a chat proposing a task and spawning an agent — now spawns an agent node on the same canvas, bound to a branch you pick in the chat node's own "Run in:" header. The agent appears just to the right of the chat that launched it.

The Tempest Bridge — Canvas Awareness for CLI Agents

An external CLI agent runs in its own process; we can't inject a system prompt or a JavaScript tool into it. So a self-launched agent used to be context-blind — it couldn't see the canvas it was born on. Not anymore.

The Tempest binary itself answers MCP over stdio when spawned with --canvas-mcp, reading straight from the app's own SQLite database. It exposes two read-only tools:

• canvas_map — every node across the project's canvases, with wiring and one-line gists.
• read_canvas_node(title) — the full body of a text node or the full transcript of a chat node (capped at 16k chars).

A tempest-canvas entry is written into the agent's working directory (.mcp.json, plus Cursor / Gemini / Kiro / opencode equivalents) on every launch path — whether the agent was proposed by a chat or started by hand from the add-node menu. No daemon, no Node sidecar, no new process type: the app you're already running is the server.

Ambient Context — The Canvas Is the Context

Nodes don't need to be wired together to inform each other. Every chat node builds its context in three tiers:

1. Canvas map. A lightweight graph of all nodes on the canvas — kind, title, a one-line gist, and the edges between them — so the model knows what exists without paying to read any of it.
2. Lineage. Wiring means something specific: a wire source → target says the target continues the source's thread. Incoming edges inject the parent's full content as inherited context — "prior work you carry forward," not a fresh task.
3. On-demand retrieval. The map is only an index; read_canvas_node(title) pulls any node's full content when the model asks. Reading no longer requires wiring.

This is the multi-agent coordination we've promised since v0.1.0. The original goal was "agents that hand off tasks and share context without file conflicts" — and the canvas is how it arrives. Multiple agents share context through the canvas map and the Bridge, while each one runs bound to its own branch and worktree, so they never touch the same working tree. A chat node launching an agent node, and agents reading each other through read_canvas_node, is the handoff. No file conflicts, because no two agents share a checkout.

Dynamic Island — Agent Status in the Title Bar

A compact island in the title bar now surfaces what your agents need, sourced from agent hooks rather than terminal-output guessing. It expands when an agent is waiting on a permission or has finished its turn, names which session, and offers a jump straight to it. Hook-based detection covers all eight hook-capable agents, with notification de-duplication so a single event never rings twice.

Canvas-owned sessions are deliberately excluded — an agent node on the canvas never pushes to the island — so the surface stays about the sessions you're actively tracking.

Per-Agent Launch Config

Settings → Agents now lets you set, per agent type: extra CLI flags, injected environment variables, and a working subdirectory. Set once, applied to every session of that agent in every project. The same loader-variable and DB-isolation deny-rules that guard tempest.yml's env apply here too, so a launch config can't turn an env var into code execution. Repo-level tempest.yml overrides still layer on top.

Worktree Setup & Teardown

Promised in v0.1.5 and now shipping: tempest.yml gains setup and teardown hooks. A fresh git worktree has no node_modules and none of your ignored files — no .env, no local config. Setup runs once after the worktree is created (install dependencies, copy secrets across from the source checkout); teardown runs before it is removed. Both stream their output live so an install that takes minutes shows what it's doing. Because the commands come from a file the repo carries, running them is gated on consent — a checked-in config can't silently execute code on your machine.

The Service Proxy — Per-Branch Ports and Hostnames

Two worktrees both running a dev server both want port 3000. This release delivers the full service proxy promised in v0.1.5:

• A port per workspace. Each worktree gets its own deterministic dev-server port (injected as PORT / TEMPEST_PORT), so parallel branches stop colliding.
• A hostname per branch. A small loopback reverse proxy routes <branch>.localhost:7000 to that branch's real port — so instead of memorizing which opaque port belongs to which worktree, you reach each one at a URL that says which branch it is. *.localhost resolves to loopback in every modern browser with no hosts-file editing, no admin, no config. The proxy peeks only the Host header of the first request and then transparently pipes the connection, so keep-alive, streaming, and WebSocket/HMR all pass through untouched. If port 7000 is taken the proxy stays dormant and the direct localhost:<port> URL keeps working.

Agents & Fixes

• Two new agents — Hermes and Pi join the manifest.
• Downloaded agents are permitted by default in project settings, instead of arriving blocked.
• Agent icons self-heal if they error while the agent is still downloading.
• Model manifest — new models ship without an app release, alongside the agent manifest from v0.1.6.

Platform Support

Platform	Status
Windows 11 (x64)	Supported. Pre-built binary available. MSI and NSIS installers.
macOS	Supported
Linux	Supported

Windows requires WebView2 (bundled automatically when necessary).

Database Branches (from v0.1.5) additionally require Docker; without it the feature stays dormant and everything else works normally.

A note on the Bridge: the release binary is a GUI-subsystem executable, and MCP-over-stdio relies on the launched agent inheriting the app's pipe handles. This is expected to work but is the one thing worth a smoke-test on a real launch — if an agent hangs at MCP connect, that's the place to look.

Still coming

Two features were named in earlier releases' "What's next" and have not shipped yet. They are not dropped — they remain committed and land in an upcoming release.

• Live quota. A title-bar island surfacing how close you are to your Claude and Codex rate-limit windows — quiet when you have room, expanding as a window fills and naming which one resets when, read from the credentials the CLIs already hold on your machine. The island and its formatting exist in this build; the piece that reads real windows from the CLIs is what remains. (Promised v0.1.5, v0.1.6.)
• Automations. Workflows you draw once as a visual graph and that then run your CLI tools without you sitting in front of them — triggering and executing like background agents, with runs and history in the same SQLite database everything else already uses. (Promised v0.1.5.)

What's next

• Live quota and Automations, above — the carried-forward commitments.
• CLI-agent chat backend. A chat node powered not only by a BYOK API key but by your connected CLI agent as the harness — the schema hook (data.backend) is already in place; the transport is the remaining work.