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 install. The instance's read and write permissions decide whether the link opens anonymously, after sign-in, for workspace members, or only for its creator and workspace owners.
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 reaches the same instance — pick whichever fits the caller. The host applies the same independent read and write permissions on every surface.
| Surface | Who it's for | Where |
|---|---|---|
| MCP | Agents (Claude, any client) | https://rect.sh/mcp — 12 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 | Typed adapter for the host runtime — 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 runtime, store, and network. A view never talks to a server
directly — it reads and writes its view model through the injected store, which
relays changes to the host over a postMessage bridge. The host persists them
(a view-agnostic JSON store whose manual write op is an RFC 7386 JSON Merge
Patch) and pushes back authoritative RFC 6902 JSON Patch deltas, 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.