# /docs/beam Beam pools the machines you own into a fleet. From any machine in the fleet you can open a shell on another, run a command there, or send a message that waits until the other machine is online. n10 Desktop uses it to run agents on your other machines. Machines connect over encrypted tunnels built with [tailcat](https://github.com/tailscale/tailcat), no Tailscale account needed. One passkey signs every machine into the fleet, and machines find each other through an encrypted directory at [beam.n10.is](https://beam.n10.is). Shells, commands and messages travel through the tunnels, never through beam.n10.is. When two machines can't connect directly, the tunnel goes through an encrypted relay. Beam is in beta. The source, the full command reference and the trust model are at [github.com/notaharness/beam](https://github.com/notaharness/beam). ## Install n10 Desktop includes Beam for its [Fleet section](/docs/guides/fleet), so you don't need Beam to use Fleet. The `beam` command is on the `PATH` only in terminals and sessions n10 Desktop starts. Install it yourself to use `beam` from any shell, or on machines without n10 Desktop, such as a headless build box. It runs on macOS and Linux, arm64 and x64. You need a passkey provider that supports the WebAuthn PRF extension, in a browser or on your phone. ```sh npm install -g @notaharness/beam ``` ## Use it Create the fleet on your first machine, then join each of the others: ```sh beam init --label laptop # on the first machine: two passkey prompts beam join --label buildbox # on every other machine: one passkey prompt ``` Each prompt opens a browser, or on a headless machine draws a QR code to scan with your phone. After joining, compare the fleet fingerprint that `beam join` prints with `beam status` on a machine already in the fleet. They must match. Then, from any machine: ```sh beam peers # the fleet and who is online beam connect buildbox # a shell on buildbox beam exec buildbox -- uname -a # one command, with its exit code beam msg send buildbox --topic jobs 'ready' # delivered now, or when buildbox connects beam msg listen --topic jobs # on buildbox: print incoming messages ``` A shell ends when the connection does, so run long-lived work in tmux: `beam connect buildbox -- tmux new-session -A -s agents`. By default every machine in the fleet can run commands as you on every other. Run `beam --help` for every command, including limiting and revoking machines. ## With n10 and Orchestra n10 Desktop's [Fleet section](/docs/guides/fleet) manages the fleet and launches agents on its machines, and [Orchestra](/docs/orchestra)'s scripts take `--machine NAME` to run a player on one; that machine needs Orchestra installed too. --- # /docs/configuration Open settings with `⌘,` (`Ctrl+,` on Linux) in n10 Desktop, or `s` in the terminal UI. Both change the same configuration. | Setting | What it does | | --- | --- | | **AI Tool** | The agent n10 launches: Claude (the default), Codex, Gemini, Copilot or OpenCode. | | **Editor** | The editor **Open in editor** uses, globally or per project. | | **Worktree Path** | Where new worktrees go, such as `../worktrees/{session}`. `{session}` is a filesystem-safe form of the branch name and `{branch}` the name itself. The default is `.claude/worktrees/{session}` inside the repository. Takes effect after a restart. | | **Sync Interval** | How often n10 fetches, fast-forwards your default branch, checks worktrees for conflicts and looks for merged pull requests. Default 1 hour, minimum 5 minutes. The pull request list refreshes every minute regardless. | | **Auto Delete on Merge** | Off by default. On each sync, removes worktrees whose pull requests have merged (on GitHub, pull requests you opened). It skips worktrees with a running agent, uncommitted changes or a rebase in progress, and main or master. | | **Auto Rebase** | Has no effect yet. | | Provider fields | The owner, repository and GitHub username (GitHub), or organization, project, repository and access token (Azure DevOps). | n10 fills in the provider fields from your Git remote when you open a repository, so you rarely set them by hand. ## Keyboard shortcuts In n10 Desktop, **Help → Keyboard Shortcuts** lists them. The ones you'll use most: | Shortcut | Action | | --- | --- | | `⌘K` / `Ctrl+K` | Search branches, pull requests and commands | | `⌘N` / `Ctrl+N` | New worktree | | `⌘⇧T` / `Ctrl+Shift+T` | New terminal | | `⌘O` / `Ctrl+O` | Open a repository | | `⌘B` / `Ctrl+B` | Toggle the sidebar | | `⌘R` / `Ctrl+R` | Refresh pull requests | For the terminal UI's keys, see [the terminal UI](/docs/terminal-ui). ## Where n10 keeps its files n10's own files are in `~/.n10/`: - `config.json`: global settings. - `projects//config.json`: each repository's settings. - `desktop-prefs.json` and `desktop-recents.json`: n10 Desktop's preferences and recent repositories. - `reviews/`: agents' draft review comments. Beam, which runs [Fleet](/docs/guides/fleet), keeps its state in `~/.config/beam`. Agent conversations live wherever each agent CLI keeps them. --- # /docs/contributing n10 is open source at [github.com/notaharness/n10](https://github.com/notaharness/n10). Work is planned on the [roadmap board](https://github.com/orgs/notaharness/projects/1); see the [Roadmap](/docs/roadmap) for the direction. Issues labelled [`good first issue`](https://github.com/notaharness/n10/labels/good%20first%20issue) are small and fully specified. To propose something new, open an issue first. [CONTRIBUTING.md](https://github.com/notaharness/n10/blob/master/CONTRIBUTING.md) is the full guide, and [SECURITY.md](https://github.com/notaharness/n10/blob/master/SECURITY.md) says how to report a vulnerability. ## Set up You need the [prerequisites](/docs/installation#prerequisites) for running n10, plus a clone of the repository: ```sh git clone https://github.com/notaharness/n10.git cd n10 npm ci ``` The repository is an [Nx](https://nx.dev) monorepo. Run tasks through Nx: ```sh npx nx serve desktop # n10 Desktop from source, with reload npx nx serve cli # the terminal UI from source npx nx dev website # this site, at http://localhost:3100 npx nx test # unit tests for one project npx nx run-many -t lint --all # lint everything; warnings fail npx nx run-many -t typecheck --all npx nx e2e cli-e2e # end-to-end tests for the terminal UI npx nx e2e desktop-e2e # end-to-end tests for n10 Desktop ``` The end-to-end tests run offline against fixture repositories and a scratch tmux server, so they never touch your own sessions. ## Working with an agent The repository is set up for coding agents. `AGENTS.md` at the root, and in the directories that need one, holds the working rules: module boundaries, lint budgets, tmux safety and how to run checks. Point your agent at it before it edits anything. The same rules apply to changes you write by hand. ## Pull requests - Branch from `master`. - Use [Conventional Commits](https://www.conventionalcommits.org) with the project as the scope, such as `fix(desktop): …` or `feat(core): …`. - Say which issue the pull request implements, and describe what the code does, not how you got there. - CI runs lint, typecheck, unit, end-to-end and visual tests on every pull request. ## How the code fits together n10 Desktop (Electron) and the terminal UI (Ink) are two shells over the same core. `libs/core` owns every sequence of Git, tmux, filesystem and provider operations, and `libs/app-core` adds the React state both shells share. Dependencies flow one way: an app may depend on libraries, never on another app. The website is standalone. ```mermaid flowchart TB subgraph Apps cli["apps/cli (Ink TUI)"] desktop["apps/desktop (Electron)"] website["apps/website (Next.js, standalone)"] end subgraph Libs appcore["libs/app-core — React hooks + controllers"] core["libs/core — no React, Ink or Electron"] vcs["libs/vcs/* — GitHub, Azure DevOps"] terminal["libs/terminal, terminal-pty, terminal-tmux"] diff["libs/diff"] worktree["libs/worktree-manager"] review["libs/review-comments"] logger["libs/logger"] end cli --> appcore desktop --> appcore appcore --> core core --> vcs core --> terminal core --> diff core --> worktree core --> review core --> logger ``` The repository's `docs/` folder goes deeper: - [architecture.md](https://github.com/notaharness/n10/blob/master/docs/architecture.md): a directory map of every app and library. - [decisions.md](https://github.com/notaharness/n10/blob/master/docs/decisions.md): design rationale and known limitations, by area. - [testing.md](https://github.com/notaharness/n10/blob/master/docs/testing.md): test fixtures, visual QA and live integration tests. - [linting.md](https://github.com/notaharness/n10/blob/master/docs/linting.md): lint configuration, budgets and exceptions. --- # /docs/getting-started This walks through n10 Desktop with a GitHub repository. It assumes you have [installed n10](/docs/installation) and its prerequisites, including a signed-in `gh` and `claude`. ## 1. Open your repository Run `n10` from the root of the repository you want to work on: ```sh cd ~/code/my-project n10 ``` n10 Desktop opens that repository. Run it anywhere else, including a subdirectory, and it opens the repository you used last, or asks you to pick one with **Open repository…**. n10 reads your Git remote and fills in the project settings: the owner and repository, and your GitHub username from `gh`. The sidebar lists your worktrees and the open pull requests that involve you: ones you opened, are assigned to, are mentioned in or have commented on. For Azure DevOps, open **Settings** with `⌘,` (`Ctrl+,` on Linux), go to **Provider** and enter your personal access token. ## 2. Create a worktree Press `⌘N` (`Ctrl+N` on Linux). Type a name for the new branch, such as `fix-login-timeout`, and choose **Create branch fix-login-timeout and open a worktree**. n10 creates the branch from the commit your main checkout is on, and checks it out in a worktree under `.claude/worktrees/` in the repository. The agent works there, so your main checkout's files stay as they are. The **Worktree Path** setting moves worktrees elsewhere. ## 3. Launch an agent When the worktree is ready, the launch dialog opens. The **Agent** selector starts on your default agent, Claude unless you've changed it. Leave **New session** selected and choose **Start new session**. The agent starts in the worktree, in a terminal pane in n10. Tell it what to do, as you would in any terminal. Agents and terminals run in tmux, so quitting n10 leaves them running, and n10 reconnects to them when you open it again. An agent that has exited keeps its last output. Claude and Codex conversations can be resumed; for other agents, start a new session. Closing a tab is different from quitting. Closing a worktree or pull request tab stops its agent, asking first only if the agent is busy. Closing a terminal tab, or choosing **Stop agent**, ends that session. To launch an agent on a worktree later, right-click it in the sidebar and choose **Launch agent…**. ## 4. Follow the pull request When the agent opens a pull request, its CI checks, reviews and conflicts show on the worktree's row. See [what the sidebar shows](/docs/guides/worktrees#what-the-sidebar-shows). ## Terminals and other repositories `⌘⇧T` (`Ctrl+Shift+T` on Linux) opens a terminal: choose a shell or an agent, and the directory it starts in. To work on another repository, use **Open Repository…** (`⌘O`) or pick a recent one from the title bar. Your open tabs stay across repositories. ## Next - [Review an agent's draft comments](/docs/guides/agent-reviews) on someone else's pull request. - [Babysit a pull request](/docs/guides/babysit) so its agent hears about failing checks and new comments. - [Configure n10](/docs/configuration): choose your agent, sync interval and merged-branch cleanup. - Prefer the terminal? See [the terminal UI](/docs/terminal-ui). --- # /docs/guides/agent-reviews An agent can review a pull request for you. It leaves draft comments on the lines it has something to say about, and nothing is posted until you post it. 1. Double-click the pull request in the sidebar to open the launch dialog. 2. Choose **Review**. Add instructions if you want the agent to focus on something, then choose **Start review**. 3. As the agent works, its drafts appear in the pull request's review rail and in the diff, sorted by severity. 4. Step through them. Edit, discard, skip or post each one, or post them all at once. Posted comments are yours: they appear under your name. The agent saves its drafts through the `n10` command, so `n10` must be on its `PATH`. Installing n10 with npm puts it there. --- # /docs/guides/babysit Right-click a pull request in n10 Desktop's sidebar and choose **Babysit pull request**. n10 then watches it for failing CI, new review comments and conflicts, and hands them to the pull request's agent. - **Batching.** n10 waits until nothing new has arrived for ten minutes, or at most thirty minutes, then sends the updates together. - **Idle gate.** It sends only when the agent's terminal has been quiet for thirty seconds. That's a sign of idleness, not a guarantee: a long, quiet tool call or a permission prompt looks idle too. - **No agent running.** If the pull request has no live agent when an update is due, n10 checks out its branch and starts a new agent with the update. - **Lifetime.** Babysitting runs only while n10 Desktop is open with that repository active. Switching repositories pauses it, and it doesn't survive a restart: turn it on again after reopening n10. Choose **Stop babysitting** from the same menu to end the watching and the automatic restarts. --- # /docs/guides/fleet Fleet shows your [Beam](/docs/beam) fleet in n10 Desktop: the machines you own, joined under one passkey. Once the fleet has a second machine, you can launch worktrees, agents and terminals on it from this one. Fleet is a section at the bottom of the sidebar, below your repositories. Before you open a repository, it sits beside the repository picker. It starts expanded; click its header to collapse it, and the header then shows the fleet's state. The machine count in the status bar, and **Show Fleet** in Settings → Machines, bring it back into view. Setting up, pairing and adding a machine happen inside the section. Its header's **…** menu, also on a right-click, shows the fleet fingerprint and holds **Reset fleet…**. Your passkey provider must support the WebAuthn PRF extension; Fleet's **Passkey compatibility** note lists what vendors document. ## Create a fleet On your first machine, choose **Create a fleet** in the Fleet section. Name this machine and the fleet, or keep the defaults, and choose **Create fleet**. Two passkey prompts follow: 1. **Create your fleet passkey** saves a passkey for beam.n10.is. 2. **Authorize this machine** uses it to sign this machine into the fleet. For each, choose **Open in browser** or **Copy link**, or scan the QR code with your phone. Check that the browser page shows the same machine name and fingerprint as n10 before you approve. Each link expires after five minutes. ## Add a machine - **Another machine with n10 Desktop**: in its Fleet section, choose **Join an existing fleet**, name the machine and choose **Join fleet**. Approve **Authorize this machine** with the fleet's existing passkey; don't create a new one. - **A headless machine**: install Beam and join from its terminal. It draws a QR code to scan with your phone. ```sh npm install -g @notaharness/beam beam join --label buildbox ``` After joining, compare the fleet fingerprint on the new machine with the one in the Fleet header's **…** menu on a machine already in the fleet (`beam status` on a headless one). In n10, answer **Matches** or **Doesn't match**. If they don't match, the machine joined a different fleet: choose **Reset fleet…** and join again. ## Launch on another machine With a second machine in the fleet, the launch dialog and the new-terminal dialog get a **Machine** selector, and the command palette gets **Open terminal on buildbox** for each connected machine. The worktree, the tmux session and the agent all run on the machine you pick, for a new branch or an existing one, and the terminal shows up in n10 like any other. That machine needs: - a clone of the repository at the same path as on this machine; - tmux 3.2 or newer; - the agent's CLI, installed and signed in. If the connection drops, the pane shows that it is reconnecting. The agent keeps running on the other machine. ## The machine list Fleet lists every machine with its fingerprint and state: connected directly or through a relay, offline, or revoked. Each machine's menu renames it on this machine, sets what it may do on this machine, and revokes it. A machine's access decides what it may open here: **Shells and messages**, the default, **Messages only**, or **No access**. ## Orchestra players on other machines An [Orchestra](/docs/orchestra) player started on another machine with `--machine` reports back over Beam. While n10 Desktop runs, it delivers those reports to the orchestrator on this machine: a Claude session, or an agent session n10 started, and only from machines allowed **Shells and messages**. n10 doesn't deliver to a Codex orchestrator; run Orchestra's `relay.sh` for that, as its [README](https://github.com/notaharness/plugins/tree/main/orchestra#other-machines) describes. ## Revoke a machine, or start over Choose **Revoke buildbox…** from a machine's menu. A dialog opens; approve its one passkey prompt. The fleet stops accepting that machine for good. Revoking doesn't erase anything on it. **Reset fleet…**, in the Fleet header's **…** menu, takes this machine out of its fleet after you type `reset` to confirm, so you can create or join one again. It doesn't affect other machines or the passkey. If you lose the passkey, reset every machine and build the fleet again. ## Limitations - On another machine, n10 can launch an agent on a new or existing branch, but can't yet check out a branch on its own, remove a worktree or rebase. - Plans go to an agent on this machine only; see [plans](/docs/guides/plans). - The terminal UI has no Fleet. - Headless machines must run macOS or Linux. --- # /docs/guides/plans When reviewers leave comments on your pull request, you can hand them to the agent working on that branch. 1. Open the pull request and choose **Add to plan** on each comment you want addressed. Use **Add to plan with a note** to tell the agent how. 2. Choose **Plan** in the pull request's review rail to see every comment in it and preview the full prompt. 3. Send it. The button depends on the agent's state: - **Send to agent** types the plan into the running agent as one task. - **Start agent with plan** appears when no agent is running. It checks out the branch if needed and starts one with the plan. - **Restart with plan**, offered beside **Send to agent**, stops the running agent and starts a new conversation with the plan. Plans go to an agent on this machine. If the branch's agent is running on another machine in your [fleet](/docs/guides/fleet), n10 refuses to send the plan rather than start a second agent here. --- # /docs/guides/reviewing-code Open a pull request from the sidebar to read its description, browse its diff and submit your review. You can reply to comments, resolve and reopen threads, and switch between split and unified diffs. n10 Desktop can also show whole files, with unchanged code folded and changes highlighted word by word. Before a worktree has a pull request, open it to review its changes the same way. The diff covers its commits, uncommitted edits and untracked files. The sidebar lists the open pull requests that involve you on GitHub: ones you opened, are assigned to, are mentioned in or have commented on. --- # /docs/guides/themes In n10 Desktop, choose **View → Theme**, then **System**, **Light** or **Dark**. --- # /docs/guides/worktrees Each branch you work on in n10 gets its own Git worktree and agent session. Switch between them from the sidebar. There's nothing to stash, and agents never edit your main checkout. - **New branch**: press `⌘N` (`Ctrl+N` on Linux), type the branch name and choose **Create branch … and open a worktree**. - **Existing branch or pull request**: find it in the command palette under **Check out branch**, or right-click its row in the sidebar and choose **Check out as worktree**. A session belongs to the worktree's directory, not to its branch name. If you switch or rename the branch inside a worktree, its agent session stays with that worktree. ## What the sidebar shows Each worktree's row shows its pull request, CI checks, review status and conflicts. The status turns red when a check fails or a reviewer asks for changes, and solid green when checks pass and every reviewer approves. Open a worktree before it has a pull request to see its changes: the diff covers commits, uncommitted edits and untracked files against the base branch. ## Keeping worktrees current On each sync, n10 fetches from origin and fast-forwards your default branch, using `git merge --ff-only` if that branch is checked out in your main checkout. It also checks each worktree for conflicts and looks for merged pull requests. **Sync Interval** and **Auto Delete on Merge** in [Settings](/docs/configuration) control this. n10 Desktop doesn't rebase worktrees. In the terminal UI, `u` rebases the selected worktree onto origin's default branch, not the pull request's target branch, and aborts the rebase if it conflicts. ## Removing a worktree Right-click it and choose **Remove worktree…**. This stops its agent, removes the worktree directory and deletes its local branch. If removal isn't safe, for example because of uncommitted changes, the dialog says why and offers **Force remove** where n10 allows it. --- # /docs n10 runs coding agents in Git worktrees and lets you review their pull requests, from a desktop app or a terminal UI. Every branch gets its own worktree and its own agent session. You can have several features and reviews going at once without stashing changes, and agents never edit your main checkout. For each worktree, n10 shows the pull request, its CI checks, its reviews and whether it conflicts with the base branch. When a pull request needs review, an agent can draft the comments and you decide which ones to post. When your own pull request gets review comments, you can hand them to an agent as one task. You can do all of this without opening GitHub.com or Azure DevOps. n10 works with Claude, Codex, Gemini, Copilot and OpenCode, and with GitHub and Azure DevOps. It is in beta: I use it every day, but expect rough edges. ## Start here - [Installation](/docs/installation): what you need and how to install n10. - [Getting started](/docs/getting-started): from installing to an agent working in a worktree. - [Guides](/docs/guides/worktrees): each feature, one page at a time. n10 has two companions. [Beam](/docs/beam) pools your machines so n10 Desktop can run agents on any of them, and [Orchestra](/docs/orchestra) lets one agent hand work to other agents. ## For agents This site publishes [`/llms.txt`](/llms.txt), an index of its pages, and [`/llms-full.txt`](/llms-full.txt), every page's content in one file. --- # /docs/installation ## Prerequisites - Linux or macOS. n10 runs every agent and terminal in tmux, which has no native Windows build. - Git 2.38 or newer, and Node.js 22.12 or newer with npm. - tmux 3.2 or newer. - At least one agent CLI on your `PATH`, signed in: `claude`, `codex`, `gemini`, `copilot` or `opencode`. - For GitHub, the [`gh` CLI](https://cli.github.com), signed in with `gh auth login`. - For Azure DevOps, a personal access token with Code (Read & Write), Build (Read) and Project and Team (Read). - On Linux, `build-essential` and `python3`. npm compiles `node-pty` during the install. ## Install One package holds n10 Desktop and the terminal UI: ```sh npm install -g @notaharness/n10 ``` Then, from a repository: ```sh n10 # open n10 Desktop n10 --tui # run the terminal UI instead ``` `n10 --help` lists every command, and `n10 --version` prints the installed version. A .deb package and an AppImage for Linux are coming, tracked in [#122](https://github.com/notaharness/n10/issues/122). Next: [Getting started](/docs/getting-started). --- # /docs/orchestra Orchestra lets one coding agent delegate work to other coding agents. The **orchestrator** splits a task into branch-sized pieces and supervises them. Each **player** is an agent in its own tmux session and Git worktree, and reports its progress, questions and results back to the orchestrator. A **dir player** works in an existing directory instead, with no branch or worktree, for reviews or work outside a repository. Orchestra is two agent skills. Claude Code and Codex can be the orchestrator; players can also be Gemini, Copilot or OpenCode. The source and full documentation are at [github.com/notaharness/plugins](https://github.com/notaharness/plugins/tree/main/orchestra). ## Install Orchestra needs Linux or macOS with Bash, Git, tmux 3.x and `python3`, and the authenticated CLI of each agent you run as a player: `claude`, `codex`, `gemini`, `copilot` or `opencode`. A Claude Code orchestrator also needs Claude Code 2.1.224 or later and `socat` or OpenBSD `nc`; without them, run it inside tmux. The [README](https://github.com/notaharness/plugins/tree/main/orchestra#requirements) has the full list. In Claude Code: ```text /plugin marketplace add notaharness/plugins /plugin install orchestra@notaharness ``` For Codex, install both skills with Node.js and npm. Leave out `--agent codex` to pick other agents from a list. ```sh npx skills@latest add notaharness/plugins --global --agent codex --skill orchestrator player ``` ## Use it Start the orchestrator with your task: `/orchestra:orchestrator` followed by the task in Claude Code, or `$orchestrator` in Codex. It spawns players as it needs them and tells you when a decision is yours to make. You can attach to any player's tmux session to watch it or talk to it directly. ## With n10 n10 lists Orchestra's worktree players next to its own worktrees, so you can follow and review their work in n10. It doesn't list dir players. With [Beam](/docs/beam), `--machine NAME` runs a player on another of your machines. That machine needs Orchestra installed at the same path under `$HOME`, the repository at an absolute or `~/` path, tmux, Git and the player's agent CLI; the README's [Other machines](https://github.com/notaharness/plugins/tree/main/orchestra#other-machines) section has the details. n10 Desktop delivers the player's reports to a Claude or tmux orchestrator on this machine. For a Codex orchestrator, run Orchestra's `relay.sh` instead. See the [Fleet guide](/docs/guides/fleet). --- # /docs/providers | Provider | Sign in with | | --- | --- | | GitHub | The `gh` CLI (`gh auth login`) | | Azure DevOps | A personal access token | n10 picks the provider from your repository's Git remote. For Azure DevOps, create a personal access token with Code (Read & Write), Build (Read) and Project and Team (Read), and enter it in Settings under **Provider**. Azure DevOps support is less tested than GitHub's. If something breaks, please [open an issue](https://github.com/notaharness/n10/issues). GitLab, Bitbucket and other providers are not supported yet. Providers share one interface, and adding one is a welcome [contribution](/docs/contributing). --- # /docs/roadmap n10 aims to be the all-in-one worktree manager. You run coding agents in Git worktrees and review their pull requests in one place, without a trip to GitHub.com or Azure DevOps. It should work well out of the box, with sane defaults, and later open up to plugins so others can extend it. The work is tracked on the [n10 roadmap board](https://github.com/orgs/notaharness/projects/1). Each epic below is an issue on that board, with its sub-issues listing the concrete work. ## Current epics - **[Launch](https://github.com/notaharness/n10/issues/133)**: the first public release of n10, Beam and Orchestra, with docs for newcomers. - **[Worktree lifecycle](https://github.com/notaharness/n10/issues/145)**: n10's tabs always match the worktrees on disk, whatever creates, moves or removes them. - **[n10 Desktop UX/UI](https://github.com/notaharness/n10/issues/151)**: everyday actions in n10 Desktop are obvious without docs. - **[beam.n10.is pairing UX/UI](https://github.com/notaharness/beam/issues/33)**: beam.n10.is explains what Beam is, says up front whether your browser can pair, and shows the pairing as it happens. - **[Vendor-neutral pull request view and diff viewer](https://github.com/notaharness/n10/issues/158)**: one pull request view and diff viewer that work the same for GitHub and Azure DevOps. - **[Cross-vendor pull request stacks](https://github.com/notaharness/n10/issues/162)** (idea): pull requests that target other pull requests' branches show as a stack, on any vendor. - **[Plugin architecture](https://github.com/notaharness/n10/issues/163)** (idea): n10 Desktop takes plugins, with features such as the Beam fleet as the first ones. To help with one, open its issue and pick a sub-issue; see [Contributing](/docs/contributing). --- # /docs/terminal-ui Run the terminal UI from a repository: ```sh n10 --tui # the repository in the current directory n10 --tui ~/code/app # or another one ``` It uses the same configuration, worktrees and agent sessions as n10 Desktop, so you can switch between the two on the same repository. If n10 detects a provider that still needs settings, such as Azure DevOps without a token, it walks you through them. `s` opens Settings at any time. From the terminal you can create worktrees, run agents, follow pull request status, read diffs and review threads, and send plans to agents. Images in comments render inline in kitty and Ghostty. With the sidebar focused: | Key | Action | | --- | --- | | `↑` `↓` | Move between worktrees and pull requests | | `c` | Check out a branch, or type a new name to create one | | `Enter` | Start or focus the agent session for the selected worktree | | `u` | Rebase the selected worktree onto origin's default branch; aborts if it conflicts | | `s` | Settings | | `q` | Quit | While an agent's terminal has focus, keys go to the agent. `Ctrl+Space` leaves it. If another agent has gone idle, `Ctrl+Space` jumps there instead; the **Jump to Inactive Session on Ctrl+Space** setting turns that off. These are the Normie defaults. Settings → **Controls** switches to the Vim preset or remaps keys. Most new work lands in n10 Desktop first. Whole-file diffs and running agents on other machines with [Fleet](/docs/guides/fleet) are desktop-only.