CLI

The inline command puts the whole platform in your terminal. It reviews your local changes with the same reviewer, repository memory and team learnings as inline’s pull request reviews, before the pull request exists. It shows the inline review and merge gate on a pull request, lists everything inline has found wrong across every feature, prints a fix brief for any of it or hands it to inline’s coding agent, and answers questions about your workspace.

It is built for coding agents as much as for people: every command has --json, long-running ones stream --events, nothing ever waits on a prompt without a terminal, and exit codes are stable.

# Install and sign in

npm install -g @pendral/inline-cli
inline login

inline login prints a short code and opens your browser at /device. Check the code matches, click Authorize, and the terminal finishes on its own. The key it gets reads what you can read and runs pre-PR reviews. It expires after 90 days and appears under Coding agents like any other key, where you can revoke it.

Run inline doctor any time something looks wrong: it checks the version, the server, your sign-in, the repository, the hook and the terminal, and says how to fix each problem.

# login

inline login                   # default access: read and review
inline login --access full     # also resolve issues, start fixes, comment on plans, read metrics
inline login --no-browser      # SSH or a container: open the printed link anywhere
inline login --no-wait --json  # for an agent: print the link and code, exit 3
inline login --complete        # then finish once the person approves
printenv INLINE_KEY | inline login --with-key

With --access full the /device page lists exactly what the key will be able to do, and you approve it by ticking a box. A key never gets more than you can grant yourself, and no terminal key can manage agents, members, roles or connections.

# logout

inline logout forgets the key and revokes it when inline login minted it. A key you pasted may be wired into something else, so it is only revoked with --revoke.

# status

inline status (or inline whoami) shows the server, the key and where it came from, who it acts as, the workspace and plan, the access tier, and whether this repository is connected.

# Reviewing changes

# review

inline review                      # staged changes, or the working tree when nothing is staged
inline review --staged             # only what is staged
inline review --working            # staged, unstaged and new files
inline review --base origin/main   # everything on this branch
inline review --deep               # codebase-wide review of the pushed commit
inline review -- src/payments      # only these paths
inline review --layout diff        # read each file with its findings in place

The review shows each stage live (context, triage, review, validation), then the findings grouped by file, worst first, each with a code frame and a file:line location your terminal can open. Add -t "what this does" and -m "why" to give the reviewer intent.

When the repository is connected to inline, its memory and your team’s learnings apply. Otherwise the review still runs on your changes and the files they touch. Press Ctrl-C to stop a review; it stops on the server too.

# review list

Your recent reviews from the terminal, the editor and coding agents, newest first.

# review show

inline review show <id> reopens one review with the same view.

# Gate CI and pushes

inline review --base origin/main --gate major

Gate levels: minor (any finding), major (medium and above), critical (high only). Findings at or above the gate exit 2. In CI, create a key under Coding agents, store it as a secret, and pass it as INLINE_API_KEY.

# hook

inline hook install --gate major

The pre-push hook reviews the commits you are about to push. It blocks the push only when findings reach the gate; if the review cannot run at all (offline, signed out), it says so and lets the push through. INLINE_SKIP=1 git push or git push --no-verify skips it, and inline hook uninstall removes it.

# Pull requests

# pr

inline pr                # this branch's pull request
inline pr 412 --resolved # include findings already resolved or held back
inline pr --web          # open it on GitHub

The newest inline review of a pull request: who opened it, its risk, the merge gate, the commit inline reviewed against your HEAD, and every open finding.

# pr list

Pull requests inline reviewed in this repository. Filter with --mine, --author <login>, --open-findings and --since 7d; --all-repos lists every repository your key can read.

# pr status

One line with an exit code for scripts and hooks: 0 the gate passes or is off, 2 it fails, 3 a review is running or your head is newer than the reviewed commit, 5 this branch has no reviewed pull request.

inline pr status && git push

# pr checks

The inline / review check: its mode, state and what blocks the merge. --watch polls until it settles, and --fail-fast exits as soon as a finding blocks. Its exit codes are pr status’s, so a check that passes on a head inline has not reviewed exits 3.

inline pr checks --watch --fail-fast && echo merged-ok

# pr review

Asks inline to review the pull request’s current head again, exactly as a push would.

# Issues and fixes

# issues

inline issues                          # this repository, worst first
inline issues -i                       # pick one, then choose what to do with it
inline issues --min-severity high --json
inline issues --all-repos --source observe_issue

Everything inline has found wrong, from every feature: review findings, runtime errors, CI failures, security alerts, documentation drift and cloud findings. Each row ends with a ref such as review_finding:abc123 that the commands below take.

# issues view

inline issues view <ref> shows one issue in full, with its evidence. --web opens it in the portal.

# fix

inline fix review_finding:abc123 | claude     # the brief, for the agent on your machine
inline fix review_finding:abc123 --remote     # inline's coding agent fixes it and opens a pull request

The brief is the same one inline’s own coding agent receives. With --remote the terminal follows the session until it opens a pull request; add --no-wait to print the session id and move on. --remote needs --access full.

After inline pr <number>, the F-1, F-2 aliases on its finding cards work here too: inline fix F-2.

# issues resolve

inline resolve review_finding:abc123 --as fixed --pr https://github.com/acme/api/pull/12
inline resolve observe_issue:9f2 --as ignored --note "known, tracked in the Q4 plan"

Records what happened to an issue, so it leaves the open list and whoever filed it can see why. dismissed and ignored need a --note. On a review finding this is your claim: the merge gate still clears on the push that changes the flagged lines, or when the thread is resolved. Needs --access full.

# resolve

inline resolve is short for inline issues resolve.

# Coding sessions

A coding session is inline’s coding agent at work on one issue: it plans the change in a sandbox, runs the repository’s own checks and opens a pull request written in the repository’s conventions. It may decline, and a decline comes with its reason.

# sessions

inline sessions                      # this repository, newest first
inline sessions --status running --mine

# sessions view

inline sessions view <id> shows where a session stands, every step it ran with its duration, the files it changed and why it ended the way it did.

# sessions watch

inline sessions watch <id> follows a session live until it ends, then prints the pull request. It exits 0 when the session succeeds or declines, 1 when it fails or is cancelled, and 3 at --timeout.

# sessions cancel

inline sessions cancel <id> stops a running session at its next safe point. It asks first on a terminal; pass --yes anywhere else. Needs --access full.

# sessions open

inline sessions open <id> opens the session’s pull request, or its portal page when it has none.

# Visual plans

A visual plan is an agent’s implementation plan, reviewed by people before any code is written.

# plan

inline plan (or inline plans) reads plans, pulls their feedback and answers it.

# plan view

inline plan view <id|url> renders the title, status, intent, steps, files and open questions, and links to the wireframes and diagrams in the browser.

# plan feedback

inline plan feedback p_8f2 --peek                  # read without marking anything delivered
inline plan feedback p_8f2 --watch --until approved

The review status and every comment the plan’s agent has not answered yet.

# plan reply

inline plan reply <id> <commentId> "<body>" answers a reviewer’s comment as the plan’s agent; --resolve closes it too.

# plan create

inline plan create --file plan.json creates a plan from the same document the create_plan tool takes and prints its share link. --file - reads it from stdin.

# Knowledge

# wiki

inline wiki lists the pages inline generated for this repository; inline wiki <slug> prints one, formatted for the terminal.

# wiki search

inline wiki search "<query>" finds the pages that match, best first.

# ask

inline ask "which repos have open critical security alerts?"
echo "what changed in the merge gate this week" | inline ask --fast

Asks the portal’s copilot and streams the answer. It reads through tools that run with your key’s permissions, across every feature, and changes nothing.

# rules

inline rules checks the repository’s .inline.yml files with the same parser a review uses and points at every problem by line. It runs entirely on your machine.

# rules explain

inline rules explain <path> shows the path instructions, filters and settings that apply to one file. --remote adds the portal’s merged settings, each with where its value came from.

# metrics

inline metrics shows the four DORA figures, where pull request time goes, how AI-authored pull requests compare and what inline saved, for this repository or, with --all-repos, every one. --window 7d|30d|90d. Needs --access full.

# Account and setup

# open

inline open opens the portal; inline open pr, issue <ref>, session <id>, plan <id>, settings and keys open those pages. --print prints the address instead.

# doctor

inline doctor checks each part of the setup and prints the fix for anything that is not right. --offline skips the checks that need the server.

# config

inline config shows every setting this CLI resolved (server, key, output, colour, width, pager, agent and CI detection, update check and auto-update) and where each value came from.

# config set

inline config set auto-update off stops background updates on this machine; on turns them back on, and also lets CI and coding agents update, which they otherwise never do. The setting is saved in settings.json in the config directory.

# completion

eval "$(inline completion bash)"
source <(inline completion zsh)
inline completion fish | source
inline completion powershell | Out-String | Invoke-Expression

The script asks the installed inline for candidates on each Tab, so it never needs regenerating.

# upgrade

inline upgrade updates a global npm, pnpm, bun or yarn install after you confirm; for npx and project installs it prints the command to run. --check only reports whether a newer version exists, and whether auto-update is on and how its last install went.

inline keeps itself up to date. At most once a day, after a command and in the background, it asks the npm registry for the latest version; when there is a newer one and inline was installed globally with npm, pnpm, bun or yarn, the same background process installs that exact version. Nothing waits on it and nothing prompts. The next command you run says Updated to inline X. once. An npx, project or source install is never touched: inline names the command instead.

• inline keeps working throughout. For a global npm install the new version is installed into a staging folder next to the current one, its binary must report the new version, and only then do its files move into place, the code before the entry point. A slow download, a failed one or the update being killed (even kill -9 or a power cut) leaves the version you had, and a release that does not run never replaces it. pnpm, bun and yarn install in place, and when the result does not run the version that worked is installed back.
• One install at a time: a lock in the config directory keeps two commands from installing at once.
• An install counts only when the new binary reports the new version. A failed one is retried after an hour, then two, then four; after three failures that version is left for inline upgrade, and the notice comes back. A release that installs but does not run is given up at once.
• If you install an older version by hand, auto-update keeps it until a release newer than the one you replaced.
• npm’s output goes to update.log in the config directory (the previous one kept as update.log.1).
• When the server no longer supports your version, the command says so on a terminal and the update starts at once. The line says what is happening: updating, checking for a newer release, that the latest release is still too old, or (for an install inline cannot update) the command to run. Scripts, CI and agents get no line; the server’s own error tells them if it refuses the version.
• Off with inline config set auto-update off, INLINE_DISABLE_AUTOUPDATE=1 or DISABLE_AUTOUPDATER=1; the daily check and its one-line notice stay. INLINE_NO_UPDATE_CHECK=1 turns both off. In CI, under a coding agent, in a pipe or with --json there is no check and no notice unless you ran inline config set auto-update on, which updates there too, silently.

inline doctor shows whether auto-update is on and the last install’s result.

# skills

# skills install

inline skills install teaches your coding agents to use inline: it writes two skills (inline-cli for the commands, JSON shapes and exit codes, inline-loop for review, fix, re-review) into .claude, .agents and .codex at the repository root. A skill file you edited is only replaced with --force.

# help

inline help <command> and inline <command> --help print the same page: usage, flags, examples and exit codes.

# For scripts and agents

• --json prints one document on stdout, errors included, with schemaVersion: 1. Errors look like {"status": "error", "error": {"code", "message", "hint", "next", "exitCode"}}, and next is the command to run.
• --events streams one JSON object per line on review, pr checks --watch, sessions watch, plan feedback --watch, ask and login. The last line is always complete (with the same document --json prints) or error.
• Data goes to stdout; progress, prompts and notices go to stderr.
• Without a terminal, in CI, under a coding agent or with --no-input, nothing prompts: a command that needs an answer exits 64 and names the flag to pass. Claude Code, Codex and Cursor are detected; INLINE_AGENT=1 or 0 overrides.
• Output adapts to the terminal: NO_COLOR, FORCE_COLOR, --plain, TERM=dumb, pipes and narrow windows all degrade to clean, stable text.

# What leaves your machine

For a review: your diff, the full contents of the changed files, and the files they import. Files that look like secrets (environment files, private keys, certificates, credentials) are never sent, neither their contents nor their changes. The check is by file name: a secret pasted into an ordinary source file is sent with the diff. Binary and very large files are reviewed from the diff alone. Every file left out is listed when the review runs. inline rules sends nothing at all.

# Usage and limits

Reviews from the CLI count toward the same monthly budgets as reviews from coding agents and appear under Coding agents, in Usage, labeled CLI.