Core concepts

On this page

Panes

A pane is one slot in the grid. Most panes are a terminal — a real PTY running a shell, an agent CLI, or anything else you’d run in a terminal, with full color, escape-sequence, and wide-character fidelity. Panes can be named (F2, or double-click the title) so a wall of agents stays legible.

The header on a narrow pane

Split the grid far enough and a pane’s header runs out of room for its icons. It doesn’t crowd them: below a threshold it keeps minimize, maximize and the pane name in the row and folds everything else — the splits, the overlay toggles, open-in-editor, the orchestration buttons, and the ✕ — behind a single ⋯ button. Hover it (or tab to it) and a small strip drops down carrying all of them, each with the tooltip and the action it had in the header.

This is automatic and there is no setting: widen the pane, or close a side panel, and the icons come back to the row. The threshold has some slack in it on purpose, so dragging a divider slowly across it settles rather than flickering. At this width the pane name is only shortened with an ellipsis — hover it for the full one. The strip floats over the terminal, so nothing about folding resizes or repaints what your shell is showing.

Keep going and the pane reaches its narrowest, where even that row does not fit. The last thing to be given up is the ⋯ button itself, which stays in the header and stays clickable at every width: the name goes first (out of the row entirely, rather than clipped to a character or two), and then minimize and maximize join everything else in the strip. At that point the strip’s first row is the pane’s name — press it to rename, exactly as double-clicking the name in the header does. The status chips step aside at that point too, for the same reason the name does: at this width there is only room for one thing, and the button that reaches everything else is the one worth keeping. A pane that needs you still says so — the header itself takes the attention tint while its chip is away. So there is never a width at which a pane has no control you can reach.

Pane kinds

Every pane starts on the welcome screen, where you pick what it becomes. There is no global mode — each pane declares its own kind:

Kind What it is
Agent A coding-agent CLI — Claude Code, Copilot CLI, Codex, OpenCode, Gemini CLI, Hermes, Ante, or your own custom command. Optionally fans out to N panes, each in its own git worktree, cut fresh from the default branch — unless that worktree name is already a branch (locally, or only on origin), which is checked out instead; if it doesn’t contain the default branch, the whole launch fails naming that branch, no pane opens, and any worktrees already cut for earlier panes of the fan-out are left on disk. Use another name, or delete the old branch, to get a fresh cut.
Orchestrator + workers An orchestrator pane plus idle workers, in its own project tab, with guardrails. See the orchestration guide.
Terminal A plain shell — PowerShell, Command Prompt, or Git Bash.
File explorer A native-style file manager rooted at a folder you choose.
File editor The file tree + code editor (the Alt+F surface) as a pane, rooted at a folder you choose.
Git The git view (the Alt+G surface) as a pane, over a repo you choose.
Workflow The repo’s agent workflow — which blocks a run may use, the path between them, the gate that must pass before a merge — as an editable pane over .orrerix/workflow.yml. Point it at a repo that has no workflow file yet and the pane offers to create one. See custom agent workflows.
SSH A remote shell — or an agent CLI on a remote host — over your own ssh client, with saved connections that hold no credentials. A solo pane: it can never join an orchestration group, and every orrerix feature that needs a local filesystem is switched off rather than left to guess. See SSH panes.

File explorer, File editor, Git and Workflow are content panes: a pane that is a surface rather than a process. No shell, no CLI, no PTY — just the surface, in a pane. They split, dock, drag, maximize and restore exactly like a terminal pane, and they never count toward a tab’s agent badge, because a viewer is not an agent.

Not every CLI in the Agent list runs everywhere. The picker offers what orrerix can launch; availability is the CLI’s own. Ante is the one standing exception worth knowing before you pick it: Antigma documents it as macOS- and Linux-only and ships no Windows binary, so on Windows it will fail to launch no matter how the pane is configured. The launcher also warns inline when a selected CLI isn’t installed. Orchestration groups are narrower still — the launcher’s own role pickers offer Claude Code, Copilot CLI, or OpenCode for orchestrator/worker/reviewer/planner. That’s a curated suggestion list, not the full set orrerix can orchestrate on: a .orrerix/workflow.yml block can also name Gemini CLI for a reviewer lane (see cross-model reviewers) — it just isn’t one of the launcher’s own dropdown options.

Notes on an agent pane

With a wall of agents open it is easy to lose track of what each one is for. An agent pane’s header carries a Notes button: click it for an overlay where you can add, read and delete your own notes about that session.

Notes are tied to the agent CLI’s session, not to the pane. So they follow the session when you resume it in a new pane, and you can read them later from the session browser without opening the session at all. Orrerix keeps them in its own file beside your other settings — it never writes to the CLI’s own transcripts.

The button appears only where a note has something to be tied to: an agent pane running a CLI orrerix recognises. A plain shell has no session, and an SSH pane’s session lives on the far-end machine.

Renaming the pane updates the name recorded against the session, so the session browser shows what you called it.

One thing worth knowing. Some agent CLIs get their session id the moment they start, because orrerix puts it on the command line — Claude Code and pi do this. Others mint their own a little later, on their first turn; Copilot CLI, OpenCode and Codex are the ones that do that today. A note you write on one of the latter before its first prompt is held in memory and attached as soon as orrerix learns the id — but if you restart the app in that window, that note is lost. The overlay says so while it applies.

The file editor and git panes

The Alt+F editor and the Alt+G git view are overlays: they float over a terminal pane, so you can see the shell underneath, and they go away when you press Esc. That’s right for a quick look. It’s wrong when you want the surface to stay — you end up toggling it in and out, or you give up a whole terminal to it.

So both are also pane kinds. Pick File editor on the welcome screen, give it a folder, and the pane is the editor: tree, code editor, project-wide search and replace, permanently. Pick Git, give it a repo, and the pane is the git view: graph, status, diffs, staging, and worktree switching. Split one beside your agent and it stays put while the agent works.

What differs from the overlay, and only this:

  • No ✕, no Esc-to-close. There is nothing to close back to — the pane’s ✕ closes it, like any pane.
  • The pane adopts a re-root. Change the editor’s root folder from its header and the pane follows: its title updates and session restore reopens that folder. (In the overlay, browsing elsewhere is deliberately view-local — it must not disturb the terminal underneath.)
  • Unsaved edits are guarded, everywhere. An editor pane holds real buffers, so closing it with unsaved changes asks first — from the header ✕, from its dock chip, or from Ctrl+Shift+W. Closing the whole tab asks too (click ✕ once to arm, again to confirm — the same two-step a tab with live agents uses), and its tooltip says what is at stake. Re-rooting the editor to a different folder asks, because the file you had open doesn’t exist under the new root. And quitting orrerix asks: one dialog listing every unsaved file across every tab — including the Alt+F editors you left open inside terminal panes, which are the ones you forget — with Quit anyway or Cancel. If nothing is unsaved, quitting is silent, as it should be.
  • Nothing automatic destroys a buffer. A pane whose process exits (or whose orchestration group is ended) stays open if its editor has unsaved edits, and its banner says so. The agent is already dead; your half-written file needn’t be.
  • Discard means discard. Answering “Discard unsaved changes?” with Discard drops the edits — the file goes back to what’s on disk, and you aren’t asked about that buffer again.
  • The git pane refreshes on open, after its own actions, and on ↻ — not on focus. Refreshing rebuilds the changes strip, which would wipe a half-typed commit message every time you tabbed away and back.

Alt+F / Alt+G inside a terminal or agent pane still open the overlays — same overlay, same sizing, same Esc. Inside a content pane there is no terminal for an overlay to float over, so the hotkey for the surface the pane already is just focuses it, and the others answer with a toast naming what isn’t available where — “The git view isn’t available in a file editor pane.” If a git view is what you want beside your editor, open a git pane; the toast won’t tell you that, this page does.

Everything else is the same code. The editor pane is the same editor; the git pane is the same git view, worktree switching included.

The file explorer pane

A file explorer pane is orrerix’s Windows-Explorer equivalent, living inside a pane. Pick a folder and you get a real file manager: browse it, open things, and do the usual housekeeping — without leaving orrerix or opening an OS Explorer window per project.

  • Browse — double-click a folder to go in; the breadcrumb and the ↑ button take you back out. Backspace (or Alt+←) goes up, arrow keys move the selection, Enter opens.
  • Double-click a file → it opens in your default app for that extension, exactly like Explorer. A .png goes to your image viewer, a .pdf to your PDF reader, a .docx to Word. Orrerix doesn’t open it and has no opinion about its type.
  • New file (Ctrl+N) and new folder (Ctrl+Shift+N) — type the name inline. A new file is created empty and is not opened; double-click it when you want it.
  • Rename (F2) and delete (Del).
  • On Windows, delete goes to the Recycle Bin, so a mis-click is recoverable — and the confirmation says so. On macOS/Linux there’s no bin, so it’s permanent, and the confirmation says that instead. It never promises an undo you don’t have.
  • A delete runs off the UI thread: a node_modules-sized folder can take a while, and nothing else in orrerix stops while it does. The row pulses, the status line names what’s going, and the ops that would write to the same tree wait their turn — but you can keep browsing, hashing and opening files throughout. There is no Cancel, because a delete stopped halfway leaves half a folder in the Recycle Bin and half on disk; once you confirm, it finishes.
  • Hidden toggle — shows hidden files, and widens the Go-to-file index to include git-ignored paths (node_modules, build output).

Right-click menu

Right-click a row for Open, Open with… (the OS chooser — Windows only), Reveal in file explorer (opens your OS file manager with the file selected), Open in file editor pane, Rename, Delete, Hash →, and New →. Right-click the empty space below the rows for New → on its own.

Open in file editor pane is the in-app counterpart to Open: where Open hands the file to the application your OS associates with it, this opens it in orrerix’s own editor, in a new pane beside the browser — rooted where the browser is rooted, so the editor’s tree shows the same project. On a folder the item reads Open folder in editor pane and roots the new pane at that folder. Either way the browser stays exactly where it was: opening a file elsewhere is no reason to move the list you opened it from.

The menu acts on the row you right-clicked — always, even if the list re-sorts or a search finishes underneath it while the menu is open. It works the same on a Go-to-file result: right-click a search hit and you get the same menu, acting on that file.

A symlink row’s actions are greyed with a reason — orrerix shows links but never follows or modifies them.

Hashes

The listing carries a short SHA-256 for every file. It is computed in the background, off the UI thread, and streamed in — opening a folder never waits on it, and navigating away cancels it. Click a digest to copy the full value.

  • Digests are cached per file, keyed by its size and modification time, so re-entering a folder is instant and editing a file re-hashes it.
  • Files over 32 MB show a hash link instead of a digest: reading a gigabyte unasked isn’t free, so that one’s your call. Click it and it hashes.
  • Hash → in the right-click menu computes any of SHA-256, SHA-512, SHA-1, CRC-32, CRC-16, CRC-8 on demand and shows the full digest in a copyable dialog. (The CRC variants are named — ISO-HDLC, ARC, SMBUS — because a bare “CRC-16” is ambiguous and you need to know which one you’re comparing against.)

This is not the in-app editor. That’s the Alt+F overlay, it still works everywhere, and it’s the right tool for a quick look or a one-line fix. The explorer is the one for “get this file into the application that owns it.”

Go to file

The Go to file box finds a file by name, anywhere under the pane’s root. It’s built to be instant: the folder’s paths are indexed once in the background, and each keystroke filters that index in memory.

  • Type any part of a name or path — matching is plain substring, case-insensitive.
  • Several terms, separated by spaces, must all match somewhere in the path: pane rest finds src/panerestore.ts, and src pane finds src/pane.ts.
  • ↑ / ↓ pick a result, Enter opens it in its default app, Esc clears the box. Opening a hit also navigates you to its folder with it selected, so you end up somewhere useful rather than back where you started.
  • Rename and delete work on a search result too, and act on that file: press F2 (or the toolbar buttons) with a result highlighted. Rename takes you to the file’s folder and opens the editor on it, so you can see exactly what you are renaming.

If more files match than the list shows, the count above it tells you — results are never cut silently. (The same box is in the Alt+F editor too, where Enter opens the file in the editor instead.)

The rest of the pane

It has no terminal underneath and never starts a process. That means the terminal-oriented chrome is gone from its header (no folder or branch chip; the overlays float over a terminal and are sized from it, so they don’t apply here — Alt+G / Alt+I answer with a toast that names what isn’t available where, e.g. “The git view isn’t available in a file explorer pane.” When it’s a git view you want over this project, open a git pane). Everything else is a normal pane: it splits, drags, docks, maximizes, renames, and comes back on session restore at the same folder. It is not an agent, so it never counts toward a tab’s agent badge.

If the folder is gone when a session is restored (deleted, renamed, or on a drive that isn’t mounted), that pane comes back as the welcome screen with a message instead of an empty listing — pick a new folder and carry on.

The split grid

  • Split right (Ctrl+Shift+E) adds a pane beside the current one.
  • Split down (Ctrl+Shift+O) adds one below.

A split only ever spends the pane you are in. The pane you split gives up half its space to the new one, and every other pane keeps its share of the screen: the layout doesn’t re-flow around the new pane. The only thing that shifts your other panes is the new divider itself, which takes a few pixels of row for its own — about one pixel per pane in a typical layout. So the pane you split repaints, and the rest normally don’t: occasionally one sits close enough to a character-cell boundary that losing that pixel costs it a column, and it repaints too. Splitting is a local edit, not a rearrangement of the tab.

Panes stay in a flat row or column as you split within one, so the dividers keep working the obvious way: dragging one trades space between its two neighbours only. Drag the divider between two panes to resize them, and a divider you moved stays where you put it.

When you launch several agents at once from one welcome screen, they are placed differently on purpose: the fleet is spread evenly across the tab as a matrix, alternating rows and columns, rather than each new agent halving what is left of the last one (which would end in unreadable slivers). A pane rejoining the grid from the dock arrives the same way — it is the grid making room, not you spending a pane.

Closing a pane hands its space back to the panes beside it in equal parts, so the smallest pane gains the most. Close one of five equal panes and the other four are four equal panes again.

Autosize

Layouts drift, and after all of the above there are three reasons rather than one.

Halving. A split spends the pane you are in, so splitting again and again into the newest pane walks the sizes down — a half, a quarter, an eighth. That is the deliberate cost of a split being local, and it is also the fastest way to end up looking at slivers.

Nesting. Even placement is even within one row or column. Split down inside a pane of a row and that pane’s slot becomes a stacked pair: the row is now shared between the panes beside it and the pair, so those come out as a half and two quarters rather than three thirds. An orchestrator opening a pane per agent nests the same way.

Dividers you dragged stay dragged — deliberately, since a position you chose is not drift.

Autosize (Ctrl+Shift+A, or the ▦ button in the top bar) gives every pane in the tab an equal share of the space, in one press — across nesting levels, which is the part a split’s own arithmetic cannot do for you. That half and two quarters becomes three equal thirds.

It happens only when you ask. A split spends the pane you are in, and a close gives that pane’s space to its neighbours — both stay inside the row or column they happened in — but nothing levels the whole tab behind your back, and a divider you positioned deliberately stays where you put it until you press Autosize. Pressing it twice does nothing the second time, and the evened-out layout is what a restored session comes back to.

If a pane is maximized, Autosize drops you out of fullscreen first — unlike a background pane joining the grid, which deliberately leaves fullscreen alone. Evening out a grid you cannot see would look like the button did nothing.

Two things it can’t do: panes have a minimum size, so a tab holding more panes than fit at that minimum can’t have them all equal; and panes end up with equal area, not identical shapes — Autosize re-sizes the grid you have, it never rearranges which panes sit beside which.

Rearranging without re-splitting

Panes get cramped fast once an orchestrator opens one per agent, so the grid can be rearranged in place:

  • Drag to reorder or move — grab a pane by its header and drag it over another. A snap preview shows where it will land:
    • drop on the middle to swap the two panes, or
    • drop on an edge (left/right/top/bottom half) to move the pane there, splitting the target — which, like any split, hands over half of that pane’s space. (Dragging a pane out of a row re-shares that row’s space among the panes left behind.)

    Release to drop, or press Esc to cancel. Swapping two equally-sized slots never resizes their terminals, so no scrollback is disturbed.

  • Maximize (Ctrl+Shift+M or the ⤢ button) blows one pane up to fill the grid; the same shortcut (or the ⤡ restore button) puts it back. The other panes are hidden rather than shrunk, so they don’t repaint. Maximize is sticky: when the orchestrator spawns an agent in the background, the new pane joins the grid underneath without dropping you out of fullscreen.
  • Minimize (Alt+M or the — button) parks a pane in the dock strip at the bottom of the grid — it keeps running. Click its chip to bring it back, or the chip’s ✕ to close it for good.
  • Fold a whole group — an orchestrator pane has a fold toggle (the collapsing chevrons) that minimizes every worker/reviewer pane in its group to the dock at once, leaving just the orchestrator. Click again to restore them all. Handy once a big group has opened a pane per agent and you want the screen back. (More in the orchestration guide.)
  • Which agent CLI is this? A pane launched with an agent wears a small mark at the far left of its header, before the role badge — in that CLI’s own colour, so you can tell a Copilot pane from a Claude one across a wall of terminals without reading the titles. Each CLI orrerix ships support for has its own hue (Claude terracotta, Codex teal, Copilot blue, opencode green, Gemini indigo, Hermes mauve, Ante citron, pi cyan); anything else keeps the violet that just means “an agent”. The same colours mark the CLI chips in the session list. Agents with a recognisable mark show it; everything else shows a lettered badge with the program’s initial (C for Claude and for Codex, O for opencode, P for pi), and ? if orrerix couldn’t make out what was launched. Hover it for the program name. A plain shell pane has no agent, so it carries no mark at all. An SSH pane shows the CLI its saved connection runs on the far end — not ssh, which is only the transport getting you there; if the connection doesn’t name a CLI, you get the neutral ? rather than a guess.

The icons are colour-coded, and the colour means something. A mark’s hue says which kind of thing it is, not what state it’s in: cyan for your workspace (folders, paths, the file actions), amber for code you edit, jade for data and documents you read, lime for git, violet for agents in general, orchid for the group’s boards (tasks, issues, audit, timeline), rose for anything destructive, azure while the mic is capturing. These hues are deliberately restrained — a muted, near-monochrome family beside the near-black ground rather than the saturated set they replace. Agent state is deliberately never carried by an icon — it has its own signals, so the two never compete for your attention. This legend is about icon marks specifically, and the one exception is the agent mark: it wears its own CLI’s colour when orrerix has one for that program, and falls back to the violet above when it doesn’t. The same hue can mean something else elsewhere on screen — lime also marks a human actor in the audit log and GitHub timeline, for instance, and orchid also colours the prototype task column — as the rest of the interface adopts this palette. The file tree uses the same scheme, which is why a listing separates folders from code from config at a glance.

Why overlays, never re-splits, for the git/issues/board/audit panels: resizing a PTY forces the program inside it to repaint, which pollutes scrollback. Orrerix’s feature panels float over the terminal instead, so the PTY box never changes size. You’ll see this promise repeated across the feature pages — it’s a core design rule.

Project tabs

The split grid above is one workspace. Project tabs give you several: each tab is a whole workspace — its own split grid and minimize dock — and switching tabs swaps the entire workspace in and out, so you can keep several projects side by side without their panes competing for space.

  • New tab Ctrl+Shift+T (or the + in the tab strip); close it with Ctrl+Shift+K (or its ✕); page between tabs with Ctrl+Shift+[ / Ctrl+Shift+].
  • A background tab is hidden, not torn down — its terminals keep running and its scrollback stays intact, and switching never repaints a terminal (the same no-resize promise as maximize).
  • Launch an orchestrator and it opens its own repo-named tab; a blocked agent in a hidden tab raises an alert on its tab so a background project can’t hide its ask.

Full details — rename/color, live previews, per-project pause, and what survives a restart — are on the Project tabs feature page.

Copy & paste

  • Copy — select text in a terminal, then Ctrl+C or Ctrl+Shift+C. Plain Ctrl+C only copies when you can SEE a selection on screen — with nothing selected, or with a selection that output has scrolled out of view, it’s your terminal’s interrupt key (^C). Copying clears the selection, and so does typing any other key, so the next Ctrl+C interrupts. Ctrl+Shift+C always copies a selection and is otherwise a no-op, so use it if you want a gesture that’s never ambiguous with interrupting a running process. There’s no right-click menu for this and no copy-on-select.
  • Paste — Ctrl+Shift+V always pastes. Plain Ctrl+V also pastes by default — turn that off if you use vim/nvim’s Ctrl+V VISUAL BLOCK mode, readline’s quoted-insert, or run anything else in the pane that wants the raw key: see Settings below.
  • If the clipboard genuinely can’t be read or written (a locked-down webview, focus loss), paste says so with a toast instead of quietly doing nothing.
  • A CLI running in a pane (e.g. an agent that says “copied to clipboard”) copies straight to your system clipboard too, via OSC 52 — no manual re-select needed.

Settings

orrerix has no settings/preferences window yet — the handful of durable app settings that exist live in a hand-editable settings.json next to tabs.json in the app’s data directory (Windows: %APPDATA%\orrerix\settings.json, or %APPDATA%\loomux\settings.json on an install that predates the rename and has not been moved yet). It’s seeded with the defaults on first run, so the file is there to find. Edit it and relaunch orrerix to pick up a change — there’s no live reload.

Key Default What changing it does
pasteOnPlainCtrlV true Set false and plain Ctrl+V in a terminal pane passes through to whatever’s running there (vim, readline, an agent CLI) instead of pasting. Ctrl+Shift+V still always pastes.
unfocusedRenderThrottleMs 100 How long a visible but unfocused pane batches its output before drawing it, in milliseconds. The pane you’re focused on is never throttled, and a pane that has been quiet still draws its next output immediately — only a pane that is already streaming, that you aren’t reading, is batched. Batching also switches off entirely while the orrerix window is hidden — see below. Set 0 to turn it off and draw every pane at full rate (see below). Values above 1000 are clamped.

Why unfocusedRenderThrottleMs exists

With half a dozen agent panes streaming at once, every visible pane redraws on every frame, on the one thread that also handles your typing. Batching the panes you aren’t reading cuts their redraws. Nothing is dropped or reordered — every byte still arrives in order, it is just drawn ten times a second instead of sixty, so a busy background pane scrolls in slightly coarser steps.

How much that helps depends on your GPU and how many panes stream at once, so it’s a knob rather than a fixed answer: set it to 0, relaunch, and compare. If orrerix feels worse with the throttle on, that’s worth reporting — and 0 restores exactly the old behaviour in the meantime.

What orrerix stops doing while its window is hidden

Minimize orrerix (or leave it fully behind another window) and every timed refresh in the UI pauses: the tab strip’s agent/cost chips, an open project panel, a hover preview, and an armed ▶ follow in the audit or timeline view. Bring the window back and each one refreshes immediately, so what you see is current rather than up to a poll-interval stale.

One thing goes the other way: the unfocusedRenderThrottleMs batching above switches off while the window is hidden, so every pane takes its output immediately instead of in batches. Batching exists to save redraws, and a hidden window has no redraws to save — while holding output back would delay the replies your panes’ terminals send back to the programs running in them. A locked screen counts as hidden, which is when that matters most.

Your agents are not paused by this. Panes keep running, output keeps arriving and scrolling, deliveries keep landing, and every backend watcher (orchestration, git, merge queue) is untouched — only the window’s own polling for things to draw stops, because nothing it draws can be seen. There is no setting: a hidden window has nothing to show, and the refresh on return is what makes that safe.

Keyboard shortcuts

The single source of truth for keybindings is src/shortcuts.ts in the repo; this table mirrors it.

Action Shortcut
Split right Ctrl+Shift+E (or ◫ in a pane header)
Split down Ctrl+Shift+O (or ⬓)
Close pane Ctrl+Shift+W (or ✕)
New project tab Ctrl+Shift+T (or + in the tab strip)
Close project tab Ctrl+Shift+K (or the tab’s ✕)
Prev / next tab Ctrl+Shift+[ / Ctrl+Shift+] (or click a tab)
Reorder tabs Ctrl+Alt+Shift+[ / Ctrl+Alt+Shift+] (or drag a tab)
Rename pane F2, or double-click its title
Move focus Alt+←/→/↑/↓ (or click)
Resize panes drag the divider between them
Reorder / move panes drag a pane by its header
Autosize panes Ctrl+Shift+A (or ▦ in the top bar)
Maximize pane Ctrl+Shift+M (or ⤢); same keys restore
Minimize pane Alt+M (or —); restore from the dock
Session browser Ctrl+Shift+P (or the sessions button)
Open in editor Alt+E (or the </> button in a pane header)
Git view Alt+G (or the lime commit-graph icon)
GitHub issues view Alt+I (or the orchid ◉ icon)
Voice prompt Alt+S (push-to-talk; Esc cancels)
Copy / paste Ctrl+C (with a selection) / Ctrl+Shift+C, Ctrl+Shift+V (Ctrl+V also pastes by default — Settings)

Orchestrator panes add a few more (steering strip, task board, audit viewer, progress timeline, lifecycle panel) — those live in the orchestration guide.

Stack (what a pane actually is)

  • Backend: Rust + Tauri 2 + portable-pty (WezTerm’s PTY layer) — real ConPTY on Windows, forkpty on macOS/Linux.
  • Frontend: xterm.js (the emulator VS Code uses) with the WebGL renderer + Unicode 11 addon, vanilla TypeScript, Vite. No UI framework.

On Windows the installer ships one prebuilt, MIT-licensed runtime — a modern ConPTY host (conpty.dll + OpenConsole.exe) for clean terminal resize. Voice input’s whisper.cpp runtime is not shipped (it would add ~150 MB); it’s an opt-in download covered on the voice prompts page.

Orrerix is MIT-licensed. This site documents what ships on main; the source of truth is the code.

This site uses Just the Docs, a documentation theme for Jekyll.