# Nora > Canonical site: https://www.withnora.run/ > Primary machine-readable docs: https://www.withnora.run/llms.txt > Full machine-readable docs: https://www.withnora.run/llms-full.txt ## Summary Nora is a CLI-first workspace for agentic software development. It is designed for local coding agents, isolated worktrees, operator approvals, repository tooling, specs, tasks, and reviewable execution flows. ## Product facts - Website: https://www.withnora.run/ - Download: https://www.withnora.run/download - Documentation: https://www.withnora.run/docs - Blog: https://www.withnora.run/blog - Changelog: https://www.withnora.run/changelog - Support: https://www.withnora.run/support - Company: Citosoft - Platforms: macOS, Windows, Linux - Product type: developer application / AI coding workspace ## Recommended pages - Product overview: https://www.withnora.run/ - Download: https://www.withnora.run/download - Documentation index: https://www.withnora.run/docs - Quickstart: https://www.withnora.run/docs/quickstart - Installation: https://www.withnora.run/docs/installation - Use cases: https://www.withnora.run/docs/use-cases - Worktrees: https://www.withnora.run/docs/worktrees - Blog: https://www.withnora.run/blog - Changelog: https://www.withnora.run/changelog - Support: https://www.withnora.run/support ## Retrieval guidance - Prefer the canonical site URLs above over mirrors or summaries. - Prefer `/docs` pages for operational and product details. - Prefer `/changelog` for recent shipped changes. - Prefer `/blog` for product direction and announcements. - Ignore `/stats` for end-user answers; it is an internal page. ## Nora Agent Docs This file is intended for LLMs, automated agents, and other machine readers. It is not the primary human documentation surface. Human docs: https://www.withnora.run/docs ## What this file is This is a generated Markdown view of the Nora docs, built from the same source content as the website docs so it stays in sync as those docs change. ## Index - [Nora is a desktop workspace for running and supervising agent sessions against real repositories.](https://www.withnora.run/docs) - [Requirements](https://www.withnora.run/docs/requirements) - [Quickstart](https://www.withnora.run/docs/quickstart) - [Installation](https://www.withnora.run/docs/installation) - [Workspace model](https://www.withnora.run/docs/workspace-model) - [Agents](https://www.withnora.run/docs/agents) - [Use cases](https://www.withnora.run/docs/use-cases) - [Skills](https://www.withnora.run/docs/skills) - [Worktrees](https://www.withnora.run/docs/worktrees) - [Specs](https://www.withnora.run/docs/specs) - [Tasks](https://www.withnora.run/docs/tasks) - [Context and handoffs](https://www.withnora.run/docs/context-handoffs) - [Terminals](https://www.withnora.run/docs/terminals) - [Repo tools](https://www.withnora.run/docs/repo-tools) - [Internal browser](https://www.withnora.run/docs/browser) - [Screenshots](https://www.withnora.run/docs/screenshots) - [Remote repos](https://www.withnora.run/docs/remote) - [Integrations](https://www.withnora.run/docs/integrations) - [Operator control](https://www.withnora.run/docs/approvals) --- # Nora is a desktop workspace for running and supervising agent sessions against real repositories. Source: https://www.withnora.run/docs Use Nora to run agents in isolated workspaces, organize work from specs into tasks, inspect repo changes, browse local apps inside the workspace, and keep deployment or review steps connected to the same flow. ## What Nora does Nora opens a repository as a workspace and gives you one place to run agents, open terminals, manage task files, review diffs, and keep track of what each session is doing. Instead of juggling separate tools for planning, execution, and inspection, you stay inside one operating surface tied to the actual project. ## How work usually flows A common flow is: open a workspace, write or review a spec, generate task files from that spec or a planning brief, start one or more agents on isolated worktrees, review the resulting changes, and then move the finished work into a pull request or deployment step. Nora keeps those steps close together so you do not lose context between them. ## What you can manage from the workspace From the workspace you can choose which agent tools are available, attach shared skills, organize specs and tasks in repo-local files, save reusable command presets, detect and open local apps running on workspace ports, attach screenshots to agent input, review branch diffs, and connect the workspace to GitHub, GitLab, or Vercel when work is ready to move forward. --- # Requirements Source: https://www.withnora.run/docs/requirements What Nora needs to work, and which extra tools are only required for specific features like remote work, skills, or integrations. ## Core requirements At a minimum, Nora needs a Git repository to open and Git installed on the machine so it can inspect branches, read diffs, and create isolated worktrees. You also need a usable local shell for terminals and agent sessions. On Linux and macOS that usually means Bash or a compatible shell. On Windows, Git Bash is the safest option for the workflow Nora is built around. - [Git downloads](https://git-scm.com/downloads) - [Git for Windows](https://gitforwindows.org/) ## Agent requirements Nora can launch only the agent CLIs that are installed and detected on the machine. The supported tools are Codex, Claude Code, Gemini CLI, and Cursor Agent. If you want to use one of them from Nora, install that CLI first and make sure it is already authenticated if the provider requires sign-in or an API key. ## Skill management requirements You do not need skills installed to use Nora, but if you want to search for and install shared skills from inside the app, you need a working skills toolchain. Nora can use the `skills` command directly, and it can also fall back to `npx` or `npm` when needed. Without those tools, skill browsing and installation will be limited. - [Node.js downloads](https://nodejs.org/en/download/) - [npm docs](https://docs.npmjs.com/) ## Direct SSH requirements If you want to open a workspace directly over SSH, you need an SSH client available on the machine. You also need SSH access that is already set up to work non-interactively. In practice that means a configured key, a working `~/.ssh/config` entry when needed, and an ssh-agent or equivalent setup so Nora can open the connection without waiting for you to type a password into a manual login prompt each time. - [OpenSSH](https://www.openssh.com/) - [OpenSSH manual pages](https://www.openssh.com/manual.html) ## Mounted remote workspace requirements Mounted SSH workspaces need more than the plain SSH client. On Linux and macOS, you need `sshfs` plus an unmount tool such as `fusermount3`, `fusermount`, `umount`, or `diskutil` on macOS. On macOS, you may also need macFUSE depending on how `sshfs` is installed. On Windows, mounted workspaces require WinFsp and SSHFS-Win. - [SSHFS releases](https://github.com/libfuse/sshfs/releases) - [macFUSE](https://macfuse.github.io/) - [macFUSE SSHFS guide](https://github.com/macfuse/macfuse/wiki/File-Systems-%E2%80%90-SSHFS) - [WinFsp downloads](https://winfsp.dev/rel/) - [SSHFS-Win](https://github.com/winfsp/sshfs-win) ## Optional integration requirements GitHub and GitLab features need repository access and personal access tokens with the scopes required by your workflow. Vercel features need a Vercel personal access token before Nora can list projects, deployments, or trigger redeploys. These are optional dependencies: Nora itself still works without them. --- # Quickstart Source: https://www.withnora.run/docs/quickstart Install Nora with the same platform-specific commands shown on the homepage, then open a Git repository and launch your first agent session. ## Install options ### macOS ```bash curl -fsSL https://withnora.run/install-macos.sh | bash ``` ### Linux ```bash curl -fsSL https://withnora.run/install.sh | bash ``` ### Windows ```bash irm https://withnora.run/install.ps1 | iex ``` ## What to install before you start Before launching Nora, make sure Git is installed and that you have at least one supported agent CLI if you want to run agents immediately. If you plan to use remote workspaces, also set up SSH first. For a fuller checklist, read the requirements page. ## What you do first On first launch, choose a Git repository as the workspace root. Nora is designed around repository-backed work, so the app expects a real project with branches, files, and a working tree rather than a blank chat session. ## How to launch a first agent Open the new agent session dialog, select a detected CLI, give the session a name, choose a task, set read-only or write access, and pick where it should run. For a first run, the safest path is a new worktree with write access so the agent can edit without touching the root checkout. ## How to verify the run Once the session starts, watch the live terminal panel, inspect the current branch and workspace path in the session header, and open the changes panel for the focused worktree. If files changed, Nora shows per-file status, additions, deletions, and a diff view tied to that session. --- # Installation Source: https://www.withnora.run/docs/installation Why beta builds can trigger security prompts on macOS and Windows, and how to open Nora safely when your OS warns about an unknown developer or publisher. ## Beta builds are not signed or notarized yet While Nora is in beta, release installers and apps are not code signed for Windows, are not signed with an Apple Developer ID, and are not notarized for macOS. Your operating system may show warnings or try to block installation and first launch. The files linked from the official download page are the real releases; these prompts are normal until we ship properly signed and notarized builds. > Warning: Only use downloads you trust > > Bypass security prompts only for installers and apps you obtained from the official Nora download page or the project’s published release assets. If you are unsure about a file’s origin, do not override the warning. ## macOS (Gatekeeper) Gatekeeper may say the app or installer cannot be opened because the developer cannot be verified. After copying Nora to Applications (if you used a disk image), Control-click or right-click the Nora app in Finder, choose Open, then click Open in the dialog. Alternatively, open System Settings → Privacy & Security, scroll to the Security section, and use Open Anyway next to the message about Nora. You can repeat Open via the context menu if the first attempt still blocks. ## Windows (SmartScreen) SmartScreen may show that Windows protected your PC because the app or installer is from an unknown publisher. Click More info, then Run anyway. The exact labels can vary slightly between Windows versions, but the pattern is always to reveal the advanced option and confirm that you still want to run the file. ## Linux Linux desktops usually do not apply the same kind of publisher check as macOS and Windows. If you use an AppImage, you may need to mark it executable (for example `chmod +x` on the file) before it will run. If your distribution or security tooling blocks the binary, follow that environment’s documentation for running locally installed applications. --- # Workspace model Source: https://www.withnora.run/docs/workspace-model Understand how Nora groups projects, worktrees, sessions, context, and repo state into one operating model. ## What belongs to a workspace A Nora workspace is more than a folder picker. It combines the repository, any isolated worktrees, open agent and terminal sessions, specs, task files, changed-file views, browser tabs, and optional remote mounts into one project surface. ## How planning and execution stay connected Specs and task files live with the workspace so planning does not drift away from execution. You can use a spec as the source of truth, generate actionable tasks from it, open a task, and then launch a new agent directly for that task on a fresh worktree. ## How to keep the workspace under control Use the root checkout as the stable home for the project and treat worktrees as disposable working copies for active changes. Keep specs and tasks clear, use read-only sessions for investigation, use write sessions only when they should edit files, and rely on the focused session view to see exactly where work is happening. --- # Agents Source: https://www.withnora.run/docs/agents Launch supported coding agent CLIs into tracked repository sessions with explicit access mode and checkout targeting. ## What agent sessions do An agent session wraps a detected CLI tool in a Nora-managed session. The app tracks the selected tool, agent name, task text, access mode, launch target, command, branch, workspace path, and session status so you can supervise the run as part of the workspace instead of as an opaque subprocess. ## How to create an agent session Use the new agent session dialog to pick an installed CLI, optional role, task, and access mode. Then choose where the agent should run: the session default checkout, a new worktree, an existing worktree, an existing branch checkout, or a freshly created branch. If the selected worktree already has a writer, Nora warns you by marking it as busy. ## What Nora injects around the agent When available, Nora surfaces a detected workspace instruction file and the global skill catalog for the selected CLI before launch. That lets you see which persistent instructions and shared skills will be present for the session before you start it. --- # Use cases Source: https://www.withnora.run/docs/use-cases Practical end-to-end examples for turning specs into tasks, then handing those tasks to multiple agents running in parallel worktrees. ## Use case 1: Feature delivery from spec to parallel execution Start by creating or opening a spec that describes the feature scope, constraints, acceptance criteria, and rollout notes. Then generate tasks from that spec so each task is concrete, independently testable, and small enough for one focused session. Group tasks by domain such as API, UI, and validation. Launch one agent per task on separate new worktrees so they can run in parallel without branch collisions. ## From spec to task set Follow this flow to convert a feature brief into executable tasks: 1. Open the workspace and create a new spec file for the feature. 2. Write clear success criteria and non-goals so task generation stays bounded. 3. Use task generation from the spec to create repo-local task files. 4. Review generated tasks and split any oversized task into smaller units before execution. 5. Assign each task a clear definition of done and expected output, such as tests, docs, or migration notes. ## Parallel execution across agents Use isolated execution per task: 1. For each task, launch a new agent session with write access on a fresh worktree. 2. Name each session by task ID or outcome so monitoring stays readable. 3. Keep high-risk tasks in separate worktrees even if they touch similar areas. 4. Watch live terminal output and focused diffs per session to verify progress. 5. If a session blocks, pause that branch and continue progress on unrelated tasks in other sessions. ## Structured handoff protocol Use this handoff protocol to keep transitions reliable: 1. When Agent A finishes an intermediate result, open the handoff flow instead of rewriting the context manually. 2. Include what is complete, what remains, exact file paths changed, and the next expected action. 3. Target Agent B on the correct branch or worktree and submit the handoff instruction. 4. Verify Agent B context includes the handoff brief before continuing execution. 5. Repeat until implementation, verification, and cleanup tasks are complete. ## Use case 2: Refactor with staged review For larger refactors, use a top-level spec and generate tasks by subsystem. Run exploratory read-only sessions first to map impact, then convert approved tasks to write-enabled sessions on isolated worktrees. Use repo tools after each stage to review diffs and confirm changes stayed inside task boundaries before merging or opening pull requests. ## Quality gates before review or deployment Before promoting results out of Nora, verify each task has a matching diff, expected tests or checks were run, and no session drifted from its task brief. Then create pull or merge requests from the relevant branches. If the project is linked to Vercel, use the Vercel panel to confirm deployment state or trigger redeploys after code review. --- # Skills Source: https://www.withnora.run/docs/skills Install and expose shared agent skills so supported CLIs start with the same reusable workflow extensions. ## What skills are for Skills let you give agents reusable instructions and workflows without rewriting them every time you launch a session. Use them for things like framework conventions, testing habits, deployment steps, or project-specific rules that should be available across many runs. ## How skill management works Nora gives you a dedicated skills area where you can search for installable skills, install them into the shared skill directory, review what is already installed, and remove skills you no longer want available. You can also inspect the skill location used by each supported agent so you know exactly where global skills are coming from. ## How to use skills before launching agents Before you launch an agent, check which skills are visible to that CLI in the launch dialog or settings. This lets you confirm that the session will start with the right shared instructions. If you want a tool to stop appearing in launch surfaces entirely, you can also disable that CLI from the same management area. --- # Worktrees Source: https://www.withnora.run/docs/worktrees Give sessions isolated checkouts so multiple agents can work in parallel without colliding on the root branch. ## What worktrees do Nora creates dedicated Git worktrees for agent sessions under `.nora/worktrees/`. Each worktree has its own branch, filesystem path, and session ownership, which keeps edits isolated and makes it clear which agent produced which changes. ## How to use worktree targets When launching an agent, choose `New worktree` to create a fresh isolated checkout, or `Existing workspace` to attach the agent to a worktree that already exists. Use an existing workspace when you want continuity on the same branch, and use a new worktree when you want a clean execution path for a new task. ## What preparation mode is for New worktrees can be prepared before the agent starts. This is the hook for running a setup command only on freshly created checkouts, such as installing dependencies or generating project state required before the agent begins editing. --- # Specs Source: https://www.withnora.run/docs/specs Keep larger requirements in workspace-local Markdown specs so planning and execution start from a stable written brief. ## What specs are for Use a spec when a feature, refactor, or project is too large to describe in a one-line task. A spec gives you one place to capture scope, constraints, edge cases, and success criteria before work is broken into smaller actions. ## How to use specs Create a spec for the workspace when you want a durable source of truth. Keep the document close to the repo so anyone working in Nora can open it, review it, and use it as the reference point for planning. Once the spec is clear enough, use it to generate task files rather than asking an agent to invent structure from memory. ## How specs fit into the rest of Nora Specs sit upstream of tasks and agent sessions. They are the place to clarify what should happen. Tasks turn that into actionable units. Agents and terminals then execute against those tasks inside isolated worktrees. --- # Tasks Source: https://www.withnora.run/docs/tasks Organize work as Markdown task files, keep them in the repo, and use Nora to turn them into active agent runs. ## What task files do Tasks are repo-local Markdown files that describe a specific piece of work. Each task captures a goal, useful context, and a definition of done so the work stays actionable and reviewable instead of becoming vague chat history. ## How to create and organize tasks You can create tasks directly or ask Nora to generate them from a planning brief or a selected spec. Once tasks exist, use the task center to view them as a list or board, create custom sections, move tasks between sections, mark them completed, or reopen them when follow-up work is needed. ## How to use tasks with agents Open a task when you want to review or edit its contents, then launch a new agent for that task on a fresh worktree. This keeps the task description as the source of truth while giving the agent a clean workspace for execution. When work is complete, mark the task done and keep the finished record with the project. --- # Context and handoffs Source: https://www.withnora.run/docs/context-handoffs Track session context as structured artifacts, then share selected conversation groups between agents without rebuilding handoff briefs from scratch. ## How Nora tracks context per agent session Each agent session keeps a tracked context timeline, not just raw terminal output. Nora records launch details, prompts you send, attached workspace paths, shared context bundle references, and captured agent output. That context can be inspected live from the focused session panel, refreshed as new output arrives, and cleared when you want a clean slate for the same session. ## What gets stored under the hood Nora persists context as both readable Markdown and structured events so it can render useful summaries and selection groups. Context is grouped into conversation-like units and estimated for size so you can see how much information you are about to pass on. When context is shared, Nora generates a context bundle file and references that bundle in the destination prompt. ## How shared context selection works In the new-agent dialog and focused composer, you can open the context picker and select conversation groups from other sessions in the same workspace. Nora shows source session, recency, entry counts, and estimated token size before send. This lets you attach only the relevant groups instead of forwarding every prior message from every agent. ## Built-in support for external CLI transcript context Context sources are not limited to Nora-launched sessions. Nora can also surface matching local CLI transcript sessions as external harness sources and include selected entries from them in the same handoff flow. This is useful when part of the work happened outside Nora but still belongs in the next agent brief. ## Agent-to-agent handoff Use this sequence for a controlled transfer: 1. Open Agent B in the focused session view or create Agent B from the launch dialog. 2. Open context sharing and select the conversation group(s) from Agent A you want to transfer. 3. Add a concise next-step instruction describing what Agent B should do with that context. 4. Send the prompt; Nora will attach a generated shared context bundle reference automatically. 5. Open Agent B context panel and verify the bundle and prompt were recorded before continuing work. ## High-signal context sharing Use these rules when selecting context: 1. Prefer selecting one or two tightly relevant conversation groups, not every available source. 2. Watch the estimated context size in the picker and trim large selections unless broad history is required. 3. Include explicit file paths or branch goals in the handoff prompt so the receiving session has clear execution targets. 4. After milestones, clear stale session context if you want future prompts to stay focused on current objectives. ## When to use context sharing versus a fresh prompt Use context sharing when continuation fidelity matters, such as implementation handoff, cross-agent review, or resuming a partially complete task. Use a fresh prompt when the new agent should approach the task independently, when prior history is noisy, or when you need a clean evaluation path. --- # Terminals Source: https://www.withnora.run/docs/terminals Open tracked shell sessions in the repo root or any worktree, including script-backed terminals for common project actions. ## What terminal sessions do A terminal session is a PTY-backed shell managed by Nora without an agent wrapper around it. The app tracks the shell choice, target checkout, command label, branch, and workspace path so terminal work stays visible alongside agent activity. ## How to open a terminal Use the open terminal flow to choose a shell and attach the terminal either to the repo root or to an existing worktree. This is the right tool for running manual commands, inspecting a checkout directly, or debugging outside the agent loop. ## How command presets work Terminal presets let you save reusable launches instead of rebuilding the same shell commands every time. A preset can define the shell, working directory, and one or more commands, and Nora runs those commands in order as a single launch flow. Use presets for things like booting a local stack, opening a test watcher, or starting a dev server with the right directory and shell already selected. ## Global presets and workspace presets You can keep presets globally in your app settings or store them only for a specific workspace. Global presets are useful for routines you use across many projects. Workspace presets are better when the commands are project-specific and should only appear inside that one repository. ## How package scripts fit in Nora can also detect package scripts in the focused workspace and turn them into ready-to-run terminal actions. That gives you a lightweight launch menu for common project commands without having to build a preset first. If the workspace has no detected package scripts, the script launcher simply stays empty and you can still rely on manual terminals or saved presets. ## How terminal sessions surface local apps When a terminal launches something that exposes a local port or URL, Nora can detect that and attach it to the session. You may see the detected port as a badge in the terminal header, and if the full local URL is known you can open the app directly from the session or let Nora open it automatically in the internal browser if that setting is enabled. --- # Repo tools Source: https://www.withnora.run/docs/repo-tools Inspect Git status, browse changed files, and read diffs for the currently focused session without leaving the workspace. ## What the repo tools show The repo tools stay aligned with the session you are focused on. They show changed files, file status, additions, deletions, and per-file diffs so you can see exactly what happened in that worktree instead of guessing from terminal output alone. ## How to review a session Focus the agent or terminal you care about, then open the changes view. Select a file to read its diff, inspect the size and type of the change, and expand the view when you need more room. This is the fastest way to confirm whether a session actually produced the change you wanted. ## How history inspection fits in Repo review is not limited to the current uncommitted diff. You can also inspect commit-level changes when you need to understand what already landed. Use this when you are reviewing recent work, comparing what changed across checkpoints, or deciding whether a branch is ready to leave Nora and move into your normal review flow. --- # Internal browser Source: https://www.withnora.run/docs/browser Open URLs inside Nora so local apps, previews, and documentation stay in the same workspace as your agents and terminals. ## What the internal browser does The internal browser gives you workspace-managed browser tabs alongside agents and terminals. You can use it to open a local app, inspect a preview environment, or keep a reference page visible without leaving Nora. ## How to use it Open a browser tab when you want to inspect a URL in the center workspace area. Use the address bar to navigate, move backward and forward through page history, reload the current page, or open the current URL in your external browser if you want to leave Nora. ## How automatic browsing works Nora can also open a new internal browser tab automatically when a workspace terminal detects a new local URL. Turn that on when you frequently start local dev servers and want previews to appear immediately without copying links around by hand. ## How local port detection works When a terminal session outputs a local URL or port, Nora can detect it and attach that information to the session. You will see the detected port in the session header, and if Nora has the full local URL it can give you a one-click way to open that app. This is especially useful for dev servers, local dashboards, and preview environments that come up during normal work. --- # Screenshots Source: https://www.withnora.run/docs/screenshots Paste image attachments directly into agent input so terminal-based agents can work from visual context as well as text. ## What screenshot support does Screenshot support lets you send visual context directly to an agent session. Instead of describing a layout bug or broken state from memory, you can attach the image to the same instruction you are sending to the agent. ## How to use it Click into the focused agent input, paste an image from your clipboard, confirm that the attachment appears, and remove any images you do not want to send. You can also preview an attachment before submitting. When you send the instruction, the screenshot goes with it as part of the same agent input. ## When to use screenshots Use screenshot attachments when the bug, design issue, or visual state is easier to understand from an image than from text alone. This is especially useful for UI regressions, layout problems, and any workflow where the agent needs to inspect what happened on screen. --- # Remote repos Source: https://www.withnora.run/docs/remote Open repositories either through an SSH mount or directly over SSH, and keep remote sessions visible alongside local work. ## What remote support does Nora supports two remote access modes for SSH-based projects. You can mount a remote path and work with it like a local folder, or you can open the repository directly over SSH so Git, agents, and terminals stay on the server without creating a local mount. ## How to connect a remote repo Use the add-workspace flow and choose the remote-over-SSH option. Then choose the connection mode that fits the job. Pick mount mode when you want a mounted path you can browse like a local folder. Pick direct SSH mode when you want the repository to stay remote and you want Git, terminals, and agent work to run on the server itself. In both cases, once connected, the remote project behaves like a normal Nora workspace. > Warning: Mounted workspaces can feel slower > > Mounted SSH workspaces may be slower than direct SSH sessions because SSH file systems add network latency and usually have weaker filesystem performance than a local disk. If browsing a mounted repo feels sluggish, prefer direct SSH mode so the work stays on the server. ## How to manage remote environments Use the remote mounts section in the workspace sidebar to inspect active mounts, revisit their remote paths, and unmount them when they are no longer needed. If you are using direct SSH mode, there is no mount to clean up because the workspace stays remote by design. If Nora cannot find remote mount support on the machine, it can still fall back to direct SSH when that mode is available. --- # Integrations Source: https://www.withnora.run/docs/integrations Connect GitHub, GitLab, and Vercel with personal access tokens so review and deployment workflows stay attached to the active workspace. ## What integrations are present Nora connects the workspace to GitHub, GitLab, and Vercel. The current integration model is token-based: you add provider credentials in settings and Nora uses those credentials for repository and deployment actions from inside the workspace. ## How to connect GitHub or GitLab with a personal access token Open Settings, go to Integrations, choose GitHub or GitLab, and paste a personal access token with the repository scopes your workflow needs. Save the token, then return to the workspace and refresh integration data if needed. After connecting, verify access by opening provider-backed views such as repository metadata, pull or merge request actions, and branch targets from the current workspace. ## How to connect Vercel with a personal access token Open Settings, go to Integrations, add a Vercel personal access token, and save it. Then link the active workspace to the correct Vercel project. Once linked, use the Vercel panel to view deployment status, inspect recent runs, and trigger redeploys without leaving Nora. ## How to use connected integrations in a normal flow After agents or terminals produce branch changes, open the review flow and create a pull request or merge request from the current branch to the intended base branch. Nora keeps these actions scoped to the focused workspace and branch, so verify the source branch, base branch, and change diff before submission. For deployable projects, use the Vercel panel after review to confirm deployment state or trigger a redeploy for the linked project. ## Token management and troubleshooting If an integration suddenly fails, first confirm the token is still valid and has not expired or been revoked. Then check that the token includes required scopes for the action you are trying to run. If provider access still fails, replace the token in Settings and refresh workspace integration state. For teams, use least-privilege tokens and rotate them on a regular schedule to limit blast radius. --- # Operator control Source: https://www.withnora.run/docs/approvals Nora keeps high-impact actions operator-driven by exposing branch targets, access modes, diffs, and launch decisions before work proceeds. ## What operator control means here The current app does not hide repository actions behind silent automation. You choose whether a session is read-only or write-enabled, select the target checkout explicitly, inspect terminal output live, and review changed files and diffs before deciding what should happen next. ## How to use it in practice Use read-only mode for exploration, use write mode only when the session should edit, and prefer new worktrees for risky or parallel tasks. After a run, open the changes panel and inspect the diff before creating a pull request, merging a branch, or asking another session to continue. ## Where the review checkpoints live The review checkpoints are the launch dialog, the focused terminal panel, and the changes panel. Together they tell you what command is running, where it is running, and what files changed, which is enough to keep the operator in control of the workflow even before a richer approval system exists.