# CLI

# 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

```bash
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`

```bash
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`

```bash
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

```bash
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`

```bash
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`

```bash
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.

```bash
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`.

```bash
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`

```bash
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`

```bash
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`

```bash
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`

```bash
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`

```bash
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`

```bash
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`

```bash
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.

| Exit code | Meaning |
| --- | --- |
| `0` | Done; findings below the gate; a declined coding session |
| `1` | The command could not do its job (network, server, a failed session) |
| `2` | Findings at or above the gate, or the merge gate fails |
| `3` | Still running, or `--watch` reached `--timeout` |
| `4` | Not signed in, or the key was rejected |
| `5` | No such issue, review, session, plan or pull request |
| `6` | Not available on this plan, workspace or key |
| `64` | Bad flags or arguments, or a prompt was needed |
| `130` | Interrupted |

## 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**.