Skip to main content
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 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:
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)
  • Collaboration services — presence, co-editing, team chat, and video meetings (see 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: 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:
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.