What is rect.sh
Live, shareable views that agents and humans edit together.
rect.sh hosts rects — live interactive views backed by a JSON view model. An agent (or a person) issues one, hands the human a URL, and from that moment both sides are editing the same state in real time: the human works in the view, the agent drives it programmatically, and everyone sees every change.
Agents are good at producing text and bad at handing people something they can act on. A chat message can describe a decision; a rect is the decision — an approval console with a real button, an intake form the client fills at their own pace, a dashboard that updates while the job runs, a contract with inline redlines to accept or reject. The agent reads the outcome back as plain JSON and keeps going.
The three roles
- The view author builds a view — with React and the
@rectsh/rectSDK, or as a single hand-written HTML file — and publishes it to rect.sh as a reusable template. - The agent discovers templates, issues a live instance with initial state, sends the human the URL, then drives it: semantic actions when the view declares them, free-form merge patches otherwise, and finally reads the result back.
- The human just opens the link. No account, no install — the URL is the access, and everything they do is visible to the agent immediately.
One template backs any number of instances. Each instance has its own view model, its own revision counter, and its own capability URL.
Four doors, one instance
Every surface below reads and writes the same instance — pick whichever fits the caller:
| Surface | Who it's for | Where |
|---|---|---|
| MCP | Agents (Claude, any client) | https://rect.sh/api/mcp/rectsh — 10 tools |
| CLI | Terminals, scripts, CI | npm i -g @rectsh/cli → rect … |
| HTTP API | Any program, no SDK needed | Plain JSON endpoints under /api |
| Browser | The human | The instance's capability URL (/r/…) |
The authoring toolkit
For building the views themselves:
| Package | What it is |
|---|---|
@rectsh/rect | The runtime state store — connect(), get/subscribe/set/update/patch. |
@rectsh/rect/react | React bindings — RectProvider + hooks. |
@rectsh/rect/actions | defineActions() — named, host-side business logic. |
@rectsh/rect/testing | An in-memory mock store for unit tests. |
@rectsh/rect/dev | A mock host for local development with HMR. |
@rectsh/rect/spec | The self-describing view spec — parse/validate/render. |
@rectsh/rect/vite | The Vite plugin that compiles a view to a deployable bundle. |
create-rect | npm create rect — scaffold a ready-to-build view project. |
@rectsh/cli | The rect CLI — publish templates, issue and drive rects. |
The mental model
The host owns the store and the network. A view never talks to a server
directly — it reads and writes its view model through the store, and the store
relays changes to the host over a postMessage bridge. The host persists them
(a view-agnostic JSON store whose only write op is an RFC 7386 JSON Merge
Patch) and pushes back authoritative snapshots, including changes made by an
agent.
Where to go next
- How it works — the full lifecycle, from authoring to reading the result back.
- Use cases — the patterns rects are built for, with runnable examples.
- Quickstart — scaffold, develop, and publish a view in a few minutes.
- Driving rects over MCP — connect an agent and run the loop.