Skip to main content
Commands for the ReasonOS platform layer: the per-branch server, the coding agent, the Atlas knowledge graph, MCP integration, stacked development, checkpoints, and cross-project proposals. Global flags are documented in the CLI overview.

rbs server

Start the RBS server: a REST API for file operations, a WebSocket terminal, an AI coding agent with streaming support, automatic port detection and proxying for dev servers, plus real-time collaboration (collaborative editing, presence, chat, and WebRTC meetings). The server is what web-based editors and development environments connect to.
The agent inside the server reads provider keys from the environment (ANTHROPIC_API_KEY, OPENAI_API_KEY, GOOGLE_API_KEY) and the model from RBS_AGENT_MODEL. Run rbs server --help for the full HTTP/WebSocket API surface (files, search, terminals, proxies, agent sessions, collaboration, meetings, chat).

rbs server init

Clone a git repository and start the RBS server on it. Designed for container/Kubernetes deployments that start from an empty container with only rbs on the path. Inherits all rbs server flags (--port, --host, --cors, and the rest above), plus:

rbs agent

Run the interactive coding agent (graph-first, multi-provider). With a prompt argument it runs one turn and exits — headless: nothing prompts, and mutations are denied unless --mode allows them. Without arguments it starts an interactive session with inline permission prompts. Alias: rbs agent2. Providers come from the environment: ANTHROPIC_API_KEY, OPENAI_API_KEY, XAI_API_KEY, GOOGLE_API_KEY, and REASONOS_LLM_URL/REASONOS_TOKEN for the hosted service.

rbs atlas

Atlas maps the workspace into a queryable knowledge graph: functions, types, classes, and files connected by calls / imports / inherits edges, clustered into communities. Query it instead of grepping. The build is pure-local — no network, no LLM, no API key required (LLM enrichment is opt-in). Two flags are shared by every atlas subcommand:

rbs atlas build

Build (or incrementally rebuild) the workspace knowledge graph.

rbs atlas query

Answer a plain-language question with a scoped subgraph.
Ranked symbol search — hits with exact file:line locations.

rbs atlas explain

Show one symbol: identity and connections, grouped by file.

rbs atlas neighbors

List one symbol’s immediate connections.

rbs atlas path

Trace the shortest path between two symbols.

rbs atlas affected

Blast radius: what breaks if this symbol changes.

rbs atlas impact

Symbol-level blast radius of this branch’s changes versus a base ref.

rbs atlas community

Show one community: label, cohesion, and members.

rbs atlas god-nodes

The most-connected symbols — what everything flows through. Alias: god_nodes.

rbs atlas export

Export the graph — html for an interactive visualization, wiki for one markdown article per subsystem.

rbs atlas report

Print the graph report.

rbs atlas stats

Show graph size and the confidence split.

rbs atlas save-result

Record a query outcome into the branch’s work-memory (stored under .reasonos/, so it travels with the branch).

rbs atlas reflect

Aggregate work-memory into lessons that boost query ranking.

rbs mcp

Manage MCP (Model Context Protocol) integrations. RBS can act as an MCP server — exposing its tools to Claude Desktop, ChatGPT, or other MCP clients — and as an MCP client, connecting to external MCP servers for additional tools.

rbs mcp serve

Start an MCP server that exposes RBS coding-agent tools, the agent’s skill corpus (as rbs://skills/* resources), and skill-composed prompts. By default it runs in stdio mode with a curated tool surface: interactive tools, agent-loop internals, LLM-spawning tools, and write tools are excluded.
Claude Desktop configuration (stdio):

rbs mcp list

List the tools the MCP server would expose. Honors the same flags as rbs mcp serve, so the output matches what a connected client would see.

rbs stack

Stacked development. A stack is a chain of branches, each built on the one below it — instead of one large pull request, you send several small ones that review and land in order. rbs records each branch’s parent in git itself (refs/branch-metadata/<branch>), so a stack survives a clone and needs no account anywhere. Alias: rbs st. When a restack hits a conflict, resolve it and run rbs stack continue; rbs stack abort unwinds it.

rbs stack init

Set up stacking for this repository: record which branch is trunk, and optionally which control-plane project the repository maps to so rbs stack submit can open change requests. Trunk is guessed from the remote’s HEAD when not given.

rbs stack create

Start a branch on top of the current one and commit to it. Alias: c.

rbs stack modify

Amend the current branch’s most recent commit with what is staged, then rebase every branch stacked on top of it. Restacking is not optional: leaving the branches above pointing at a commit that no longer exists is how a stack rots. Alias: m.

rbs stack absorb

Look at what is staged, work out which branch below introduced the lines each hunk touches, amend those branches, and restack — review feedback lands in the change request being reviewed instead of a fixup commit on top. A hunk moves only when its lines clearly belong to exactly one branch; everything else stays staged, with the reason listed.

rbs stack log

Show the stack. Alias: l.

rbs stack ls

List the stack, one line per branch. Alias: list.

rbs stack info

Show one branch’s place in its stack (defaults to the current branch).

rbs stack diff

Print the diff a reviewer of this branch sees: its changes against its parent, not against trunk. The fourth branch in a stack shows its own change, not the sum of the four.

rbs stack checkout

Switch to a branch in the stack. Alias: co.

rbs stack up

Move up the stack, optionally by n branches.

rbs stack down

Move down the stack, optionally by n branches.

rbs stack top

Go to the top of the stack.

rbs stack bottom

Go to the branch just above trunk.

rbs stack restack

Rebase branches back on top of their parents.

rbs stack continue

Carry on after resolving a rebase conflict.

rbs stack abort

Undo an in-progress restack.

rbs stack submit

Push each branch of the stack and open (or update) a ReasonOS change request for it, each targeting the branch below rather than trunk. The stack metadata is pushed too, so the control plane and your teammates see the same graph you do. Every branch must be restacked first: a change request whose base has moved shows a diff nobody wrote.

rbs stack sync

Bring the repository up to date: fast-forward trunk from the remote, refresh what each branch’s change request says, delete branches whose changes are already in trunk (reparenting whatever was stacked on them), and restack what remains. A branch counts as landed when its content is in trunk — squash- and rebase-merges included, which plain ancestry misses.

rbs stack get

Download a stack from the remote: fetch a branch and every branch below it, reconstructing the stack from the metadata the submitter pushed — no server call involved. A local branch the remote is strictly ahead of is fast-forwarded; one strictly ahead of the remote is kept. When the two have truly diverged, get refuses unless told how to reconcile.

rbs stack test

Check out each branch in turn and run a command there — the way to ask “does every change request in this stack pass on its own?”. The command runs through sh -c at the repository root; the branch you started on is restored afterwards.

rbs stack move

Rebase a branch and everything above it onto another branch. Alias: mv.

rbs stack reorder

Rearrange the branches of a stack. Names are given bottom-first: the first sits on trunk, the second on the first, and so on. Every branch is then rebased into its new position.

rbs stack split

Cut the current branch’s commits into a stack. --at takes commit offsets from the branch head, newest first: --at 0 --at 2 means “one branch ending at the head, one ending two commits back”. --names takes the branch names oldest first, one per cut.

rbs stack squash

Collapse the current branch’s commits into one.

rbs stack fold

Combine the current branch with the one below it. By default the parent’s name survives.

rbs stack edit

Interactively rebase the current branch’s own commits.

rbs stack rename

Rename the current branch.

rbs stack delete

Delete a branch, reparenting whatever was stacked on it.

rbs stack pop

Delete the current branch but keep its changes in the working tree.

rbs stack track

Add an existing branch to a stack.

rbs stack untrack

Remove a branch from its stack, leaving its commits alone.

rbs stack undo

Restore every branch and its stack metadata to how they were before the last mutating stack command. Branches created since are kept (just untracked), so undo never deletes commits. Running undo again redoes.

rbs checkpoint

Manage workspace checkpoints that capture file state at a point in time. Checkpoints work like save points — create one before making changes, then revert back if needed (similar to Cursor and Claude Code’s checkpoint systems for undoing AI-generated changes). Alias: rbs cp.

rbs checkpoint create

Create a checkpoint of the current file state. With no files specified, all modified files (detected via git status) are included.

rbs checkpoint list

List all checkpoints, most recent first.

rbs checkpoint diff

Compare the current workspace state against a checkpoint — which files have been modified, added, or deleted since it was created.

rbs checkpoint revert

Restore all files to their state at the given checkpoint. Files that did not exist when the checkpoint was created are deleted; files modified since are overwritten. The checkpoint ID can be a prefix, as long as it uniquely identifies one checkpoint.

rbs checkpoint chain

Walk the parent links from a checkpoint back to the root of its session, showing how checkpoints are stacked.

rbs checkpoint delete

Delete a checkpoint.

rbs checkpoint prune

Remove checkpoints older than a specified duration and garbage-collect orphaned blobs.

rbs propose

File a change proposal against a project on the control plane. Public projects accept proposals from anyone (with a claimed identity — defaults to your git user.name/user.email); private projects require access. A proposal is advisory: whether anything changes is entirely up to the project’s contributors.