> ## Documentation Index
> Fetch the complete documentation index at: https://docs.reasonos.com/llms.txt
> Use this file to discover all available pages before exploring further.

# The ReasonOS Editor

> A web-based IDE that connects to a branch node — one live development environment per branch, shared by everyone working on it.

The ReasonOS editor is a full IDE in your browser. It doesn't run against your
local checkout — it connects to a **branch node**: a server that owns a live,
fully provisioned workspace for one branch. The node clones the code, builds
it, runs your terminals and dev servers, hosts the language servers and the AI
agent, and serves the editor everything it shows you.

## One server per branch

Every active branch gets its own node — server per branch, **not** server per
developer:

1. You create a branch (or open one that doesn't have a node yet).
2. A node spins up for that branch and clones the code. The editor shows a
   provisioning screen while it starts.
3. The editor connects to that branch's node.
4. Anyone else opening the same branch connects to the **same node** and works
   in the same live workspace with you.

Because a node *is* a branch, **switching branches means connecting to a
different node**. Picking another branch from the editor's branch menu
navigates you to that branch's workspace — it never runs a checkout on a
server your teammates are using. If the node's checked-out branch ever drifts
from the branch you asked for, the editor shows a warning banner.

### Ephemeral nodes, durable branch state

Nodes are disposable. The node-local `.rbs/` directory holds build outputs,
toolchains, checkpoints, and notifications — state that can always be rebuilt
from the code. Anything durable — agent chats, plans, memories, task cards —
lives in the **committed `.reasonos/` tree**, so it travels with the branch
through git rather than with any particular server. See
[Collaboration](/editor/collaboration) for the full split.

## The backend: `rbs server`

A branch node is an `rbs server` process. On the managed platform, nodes are
started for you; you can also run one yourself against any workspace and point
the editor at it over a local connection:

```bash theme={null}
# Start a node for the current workspace (default port 8080)
rbs server

# Or clone a repository and serve it in one step
rbs server init --git https://github.com/org/repo.git --path /workspace --branch main
```

The server provides everything the editor needs:

* A **file API** — list, read, write, create, delete, plus real-time file
  change notifications
* **Search** — streaming content search across the workspace and fuzzy
  file-name search
* **WebSocket terminals** — real interactive shells running on the node, with
  remote process control (send Ctrl+C to a dev server from anywhere)
* **Automatic port detection and proxying** — when a process starts listening
  on a port, the node creates a proxy URL so the app is reachable through the
  node itself
* An **AI coding agent** with streaming responses that can read the codebase,
  edit files, search, and run commands
* **Git operations** — status, diffs, staging, and hunk-level revert, surfaced
  in the editor's source control panel and gutter
* **Language servers**, provisioned automatically per detected language (see
  [Language Intelligence](/editor/language-intelligence))
* **Collaboration services** — presence, co-editing, team chat, and video
  meetings (see [Collaboration](/editor/collaboration))
* The **Atlas** knowledge graph and the branch **task board**

## The editor at a glance

The editor is organized around five main views, switched from the top bar:

| View      | What it shows                                                               |
| --------- | --------------------------------------------------------------------------- |
| **Code**  | The editor itself: tabbed files, split view, in-file search                 |
| **Graph** | The workspace build graph — targets, their dependencies, infra and CI nodes |
| **Atlas** | The symbol-level knowledge graph (see [Atlas](/editor/atlas))               |
| **Tasks** | The branch's kanban board, backed by the committed `.reasonos/` tree        |
| **Jobs**  | Cluster jobs with live streaming logs                                       |

Around the code view:

* **Sidebar panels** — the file explorer (with git status decorations and
  per-file presence — who's looking at what), streaming content search,
  semantic search with the generated Atlas wiki, and a source control panel
  for staging, diffs, and reverting hunks.
* **Right tool pane** — the AI agent chat (streaming responses, tool-call and
  diff previews, plan cards, permission prompts, checkpoints, and session
  history), an embedded browser for previewing your running app, video
  meetings, and team chat.
* **Bottom dock** — multi-tab terminals running on the node.
* **Quick open** — fuzzy file finder (Cmd+P).
* **Notifications** — a notification center; task questions and lifecycle
  events deep-link straight to the relevant card.
* **Settings** — AI provider and model configuration, editor preferences, and
  the resolved environment for the workspace.

In the code editor you get language-server completions, hover documentation
and diagnostics, a git gutter with inline diffs and hunk revert, AI ghost-text
completions, and — when collaborative editing is on — your teammates' cursors
and selections.

## Previewing your app

Run your dev server in a node terminal:

```bash theme={null}
rbs run dev_server
```

When the process starts listening on a port, the node detects it, registers a
proxy, and the editor opens the app in its embedded browser — no tunnels or
port forwarding to set up. Because the proxy lives on the node, the same URL
works for everyone connected to the branch.