livedocuments is a command line for the livedocuments API. It is built first for coding agents (an agent working in your repository, or one changing a document while you talk to it) and second for scripts: finding documents, reading a tab as text, changing it with edit operations, answering comments, and syncing documents to files.
It sits beside the MCP server, not in place of it. Both call the same API with an API token, and the API owns every change, so an older copy of the CLI never writes the old way.
Install
The CLI is the npm package @livedocuments/cli and needs Node 22 or later. Run it without installing:
npx @livedocuments/cli --help
or install it, which gives you the livedocuments command:
npm install -g @livedocuments/cli
livedocuments --version
The examples below use the installed livedocuments; with npx, put npx @livedocuments/cli in its place.
Sign In
You need a livedocuments account: the CLI acts as you, through an API token, and never as a guest. There are three ways to give it one. Whichever you use, the CLI checks the token with the API before keeping it.
In the Browser
livedocuments auth login
The CLI opens a sign-in page in your browser (and prints its address, in case the browser does not open). Sign in if you are not already, and you reach an approval card, Connect livedocuments CLI. Leave Read-only access off to let the CLI change documents, or switch it on so it can find and view documents but not create, edit, delete or share them. The card also says where the access goes: your own computer, 127.0.0.1 and a port number. Choose Connect, and the page says You're signed in: return to your terminal.
The terminal waits up to ten minutes for you. If the browser cannot reach it (on a remote machine, say), use a device code instead.
On a Machine Without a Browser
livedocuments auth login --device
The terminal prints a page address, https://livedocuments.app/oauth/device, and a code of eight letters such as BCDF-GHJK, plus a link with the code already filled in. Open the page on any device, sign in, type the code under Code shown in your terminal and choose Continue. You then see a Connect livedocuments CLI card with the same Read-only access switch; choose Connect, and the page says You're connected. The terminal carries on by itself.
A code lasts ten minutes. If the page says it couldn't find the code, check it and try again; if it has expired, run the command again for a new one. Choosing Cancel on the page stops the terminal waiting. Only enter a code that a terminal you are using is showing you.
With an API Token
For CI, sandboxes and agents, create a token on liveworkspace.app, and either set it for the commands you run:
export LIVEDOCUMENTS_TOKEN=lwt_your_token_here
or store it for this machine, reading it from stdin:
printf %s "$TOKEN" | livedocuments auth login --with-token
LIVEDOCUMENTS_TOKEN takes precedence over a stored sign-in. There is deliberately no --token flag, because a token on the command line ends up in shell history and transcripts.
Check or Sign Out
livedocuments auth status # host, account, token name, role, expiry, and where it came from
livedocuments auth logout # revoke the stored token and forget it
auth status never prints the token itself, and warns you when it has under 14 days left. auth logout revokes the token with livedocuments, so it stops working everywhere at once. It will not revoke a token from LIVEDOCUMENTS_TOKEN, which is not the CLI's to revoke: unset the variable, or revoke that token on liveworkspace.app.
The browser and device sign-ins create an ordinary API token named livedocuments CLI. It appears with your other tokens on liveworkspace.app (marked read-only if you chose that), lasts six months, and counts towards your 20. Signing in again on the same machine replaces it and revokes the old one.
Where Your Token Is Kept
A stored token goes in your operating system's own secret store: the macOS Keychain, the Secret Service on Linux (through secret-tool), or on Windows the token sealed to your user account by Windows' own data protection. Where that store is unavailable, the token is kept in ~/.config/livedocuments/credentials.json, readable only by you, and the CLI tells you so when it stores it there. If it finds that file readable by others, it tightens it and warns you.
Find and Read Documents
Commands are a resource, then a verb. doc and el are short for document and element.
livedocuments document ls launch # documents whose name contains "launch"
livedocuments tab ls "Launch deck" # the document's tabs
livedocuments tab view "Launch deck" # the first tab, as an outline
livedocuments tab view "Launch deck" --tab Slides --view graph
livedocuments tab lint "Launch deck" # what is wrong with how it is drawn
livedocuments tab render "Launch deck" --png launch.png
document ls covers your personal library and every team you have joined, newest first. Wherever a command takes a document, you can give its name, the start of its id, or a pasted livedocuments link; a share link acts through that link. A name that matches more than one document is refused with the candidates, rather than guessed. --tab takes a tab name or the start of its id, and the first tab is used when you leave it out.
tab view reads a tab as text, the outline by default; --view picks graph, layout, comments, show (one element, with --ref) or find (with --text), and --budget fits it to about that many tokens. tab render writes a PNG or SVG preview and prints its path and size, never image bytes.
A few commands read livedocuments's catalogues rather than your documents, which helps before writing anything:
livedocuments template ls # the templates a document or tab can start from
livedocuments template view slide-deck # one template, as the outline of the tab it builds
livedocuments icon search "message queue" # icons by name, best match first, for iconId=
livedocuments schema sticky # the element kinds, or one kind's fields and values
Change a Document
livedocuments document create "Shop" -f arch.json # from an elements file
livedocuments document create "Pitch" --template slide-deck
livedocuments element set "Launch deck" n3 label="Beta" shape=stadium
livedocuments edit "Launch deck" -f ops.txt # many edit operations at once
livedocuments changeset revert "Launch deck" cs_8k2m4q7d1x
livedocuments tab add "Launch deck" Details -f detail.json # a new tab, empty, from a file or --template
livedocuments tab rm "Launch deck" Scratch # delete one tab; the others stay
Every change is one changeset, applied all or nothing and checked against the version of the tab you last read, so the CLI never silently overwrites someone else's work. Each write prints what changed, the new revision, a lint summary and the command that reverts it. Add --dry-run to see the plan without writing anything, and --summary to say what the change is for. livedocuments guide edit explains how edit operations read.
document rm moves a document to the Trash for 30 days, and document restore brings it back to its folder (or the top level, when that folder is gone); the CLI has no permanent delete.
Comments and Waiting
livedocuments comment ls "Shop"
livedocuments comment add "Shop" api "Should this be idempotent?"
livedocuments wait "Shop" --for comment --timeout 600
livedocuments watch "Shop" # stream changes until you stop it
wait blocks until someone comments or the document changes (a burst of edits counts as one change), prints it and exits, which lets an agent respond to the people working beside it. Comments the CLI adds are yours.
Pages and Articles
A tab's pages (infographics and slides) and articles have their own commands:
livedocuments page ls "Pitch deck" # each page, its refs, articles and layouts
livedocuments page set "Pitch deck" --add slide --layout slide-title # add, lay out, move, copy or delete pages
livedocuments article get "Project brief" > brief.md # an article as Markdown
livedocuments article set "Project brief" brief.md # write it back, or a new one
page set makes one change from its flags, or up to 50 from a JSON list with --changes. article set writes over the article you name with --article, adds after its last block with --append, or starts another with --new, and the editor flows the text onto as many pages as it needs.
Files, Exports and Pictures
livedocuments pull "Shop" --to docs --svg # docs/shop.livedocuments.json, plus an SVG per tab
livedocuments push docs/shop.livedocuments.json # send back each tab whose elements changed
livedocuments export --all --to backup --format json,svg,md
To draw beside your agent inside a developer tool, see Documents in Your Developer Tools.
pull writes the document in the format the editor imports, and never overwrites a file holding changes you have not pushed yet (add --force to drop them). push sends each changed tab as a changeset; a tab that changed on livedocuments since you pulled it is refused and named, so pull again. Only elements travel: each changed tab's elements are replaced by the file's, so an element you removed from the file is removed from the tab, and a tab the document lacks is created. Changes to a tab's name, theme or background are not sent (a tab a push creates goes up with its name), and no tab or document is ever deleted by a push. export --all writes every document you can read, for backups and docs.
Help, Guides and the Agent Skill
livedocuments --help # the resources and four starting commands
livedocuments tab --help # a resource's verbs
livedocuments tab view --help # usage, flags and examples
livedocuments guide # how-tos: build, edit, views, comments, collaborate, workbench
livedocuments skill install --to ~/.claude/skills
livedocuments skill print > SKILL.md
Help is kept short so an agent pays only for what it asks. skill install writes a SKILL.md that tells a coding agent when to reach for the CLI; without --to it lists the usual skills folders (such as ~/.claude/skills for Claude Code). skill print writes the same file to stdout, for agents that keep their skills somewhere else. livedocuments api GET /documents calls any API path with your sign-in, as an escape hatch.
Output and Exit Codes
The CLI never prompts when its input or output is not a terminal, so it is safe in pipes, scripts and CI. stdout carries only data; hints, warnings and errors go to stderr. Output is compact text; --json gives the same data as JSON, --json=id,name picks fields, and -q prints only refs or ids. A list that was cut short ends with a line saying how to see the rest.
| Exit code | Meaning |
|---|---|
0 | Done |
1 | Refused: the input was understood but not accepted |
2 | Usage: the command line does not parse |
3 | Not found, or ambiguous: a document, tab or element |
4 | Not signed in, or not allowed (a read-only token's writes) |
5 | Conflict: the tab changed since you read it; read, retry |
6 | Rate limited |
7 | Network or server failure |
Every error names what was wrong and suggests one command that fixes it. Set LIVEDOCUMENTS_DEBUG=1 to see what the CLI is doing, on stderr.
Errors and Rate Limits
The CLI is subject to the same limits as any API client, per token: on the hosted service, 300 writes and 120 reads a minute. Over that, a command exits with 6 and asks you to wait a minute and retry. A read-only token's writes exit with 4. Errors and Rate Limits has the full list and the status codes behind these exit codes.
Usage Counts
The CLI counts which commands succeed, and which fail because of the server or the network, by the command's name only (never its arguments, your documents or the host), and sends the count to the host it talks to, as anonymous telemetry. The first time it counts one, it says so. Turn it off with livedocuments telemetry off, LIVEDOCUMENTS_TELEMETRY=0 or DO_NOT_TRACK=1.
Keep It Safe
A full-access token can change and share everything you can. Give an agent a Read-only access
token when it only needs to read, keep LIVEDOCUMENTS_TOKEN out of source control and logs, and
revoke a token on liveworkspace.app (or with livedocuments auth logout) the moment you no longer
need it or think it may have leaked.
Was this article helpful?