CLI reference

Use the artor CLI to publish prototypes, read feedback, and manage your team’s shared setup. Run commands from your prototype’s folder. If you haven’t installed it yet, follow Installing the CLI.

If you belong to more than one organization, check Organization context before running commands in a new folder.

Help, references, and confirmations

• Help: artor <command> --help, -h, or artor help <command> shows usage without running the command. Help works offline and before sign-in.
• Names: most commands accept an exact name, ID, or unique part of a name. If several items match, Artor asks you to be more specific. link needs an exact project ID or slug.
• Confirmations: destructive commands ask first. --yes or -y skips that question; unattended runs must include it when required. Use exact names or IDs when skipping confirmation for deletion, sharing, or access changes.
• Overwriting files: pull --force needs exact project and organization references. It overwrites local files, so save anything you need first. skill pin --yes also needs an exact skill reference.
• Flags: --flag value and --flag=value both work. Always provide the target value for organization, scope, version, and mode selectors.
• Agent output: use --json where listed below for output an agent or script can read.
• Color: NO_COLOR disables terminal colors. FORCE_COLOR enables them in redirected output; NO_COLOR takes priority.

For a public link, copy its ID from artor share list, or use a unique prefix of at least four characters. For a comment thread, use its full ID, short ID, or a quoted row number such as "#3". Use the same --version, --open, and guest filters you used to list it.

Version & update checks

Global and packaged installations can update automatically after an interactive command. Project-local installations, npx, and CI show an update notice instead. Set ARTOR_NO_AUTOUPDATE=1 to disable automatic CLI updates for one run.

If an upgrade is required to continue, an eligible installation updates and retries the command once. Otherwise, run artor update when prompted.

The CLI also reminds you when an Artor skill update is available. For optional automatic Claude Code plugin updates, see Keeping the skill up to date.

Auth & project

Without a terminal or destination flags, init uses the Organization Space’s Draft folder. --folder selects an existing exact name or ID, or creates a folder if that name is new. An organization or Space that can’t be found stops setup; Artor doesn’t silently choose another.

Publish & view

Changelog

Every version can carry a short note explaining what changed. Add it when publishing:

artor publish -m "Fixed navigation on mobile"
artor publish --message "Updated the signup screen from review feedback"

The note appears beside the version in the dashboard. Owners and admins can edit it there later; changing the note does not change the prototype.

Notes support text and Markdown links, up to 2,000 characters. Images and embeds are not included. An empty note is ignored; an oversized note must be shortened before publishing.

The Artor Claude Code skill can draft the note from your changes. Review it before publishing. A message you provide yourself takes priority.

Reading a crashed version’s logs

artor logs latest
artor logs v3 --json

Read a prototype’s error output to help your coding agent fix it. Use an alias or version number; without one, the command uses latest. You can also open the version’s Details → Logs in the dashboard.

A running version shows its recent output. A version that failed to start shows the captured startup error. If no output was captured, Artor reports “No logs captured.” Startup capture is limited to 512 KB per version and does not cover a crash that happens after startup.

Artor hides exact matches of saved environment values from logs. It may not recognize a value your prototype changed before printing, so check logs before sharing them. See Runtime errors for next steps.

Public sharing

Create a public link so someone without an Artor account can open a prototype. Choose whether they can comment when creating the link. See Public sharing for links, durations, and guest commenting.

<share> is a link id from artor share list, or a unique prefix of one (at least four characters, resolved against the linked prototype’s own links). A full id works from anywhere.

A live link’s guest-commenting mode and its password are changeable from either surface: share set here, or Edit on the link’s row in the dashboard’s Public sharing panel. Whether signed-in members see the review widget can be set when you create the link (the dashboard’s “Show the review widget” switch, or --hide-widget here), and changed later in that same Edit dialog. Allow new comments and repointing a link to another version stay dashboard-only, in that same Edit dialog.

share set needs a current CLI. Run artor update if the command isn’t recognised.

Link passwords

A public link can ask visitors for a password before it opens. Add one when creating the link, or set, change, and remove it later:

artor share add --password                # prompts, hidden, typed twice
printf %s "$LINK_PASSWORD" | artor share add --password-stdin
artor share set <share> --password        # change a live link's password
artor share set <share> --remove-password # remove it

A password is never a flag value: --password=secret is refused, so the password can’t land in your shell history or process list. --password prompts for it twice and checks the rules (8 to 128 characters) on the first entry. --password-stdin reads it from a pipe for scripts, dropping one trailing newline.

--remove-password is refused while your organization requires a password on public links. When that requirement is on and you run share add without a password flag, an interactive terminal says so and asks for one, then creates the link. An unattended run stops with an error naming the two flags.

Link passwords require CLI 0.26.0 or newer. Against an older Artor deployment the command exits with an error saying the password was not set, and reports any commenting change that did apply. See Public sharing.

Spaces

A Space decides which organization members can open and work on a group of prototypes. See Spaces.

<space> accepts an id, name, or unique part of the name. For space read and space members add|rm, a partial match on a terminal is confirmed with the full Space name before the change. Pre-approved and non-interactive runs require an exact reference. Members are referenced by email or user id; run artor org members for the roster. See Spaces.

Folders

Group prototypes into colored folders within a Space. Folders organize work; Spaces determine access. See Organizing with folders. Folder commands act on the linked folder’s organization — run them inside a folder linked to organization A and you manage organization A’s folders.

A folder is referenced by id or name, a prototype by id, slug, or name. Both accept a unique partial match, and --space <name|id> scopes list / create / move to another Space. folder rm and folder clear require an exact folder reference when run with --yes or without a terminal. See Organizing with folders.

Env vars

Set configuration for the organization, a project, or one version. A linked folder defaults to project scope. Values marked --local can be downloaded; server-only values cannot. See Environment variables for how to choose and use them.

Organization set / rm require an owner or admin. Project/version changes require a publisher seat and permission to edit that Space. Members can list names for prototypes they can access. Pulling project values requires a publisher with source access; any member can pull organization-wide local values.

Use --scope org for organization values and --version <ref> for one version. Prefer --scope org over the deprecated bare --org. See Environment variables.

Mock datasets

Add sample data for the organization, a project, or a version. Published versions keep their data when organization/project defaults change; explicit version edits change the selected version. See Mock datasets.

Organization writes require an owner or admin. Project/version writes require a publisher seat and permission to edit the prototype’s Space. Members can read and compare datasets for prototypes they can access.

Use --scope org for shared organization data; the bare --org selector is deprecated. pull, status, and promote use the linked project and take no scope flag. promote selects its source version with --ref. See Who can do what.

Org skills

Share instructions with your team’s AI tools. The commands marked with a lock use the default admin-only setting; an admin can allow all members to manage skills and templates. See Org skills.

Starter templates

Use a template: artor init --template <slug>.

Usage

Without --org, this uses the linked folder’s organization or your saved default. Storage measurements are periodic; check the reading’s age. The same figures appear in Settings → Usage. See Usage.

Private registry

Map private packages to your organization. See Private registry.

Unlinking a folder

artor unlink removes the local setup that init / link wrote. It never deletes your code, and it never touches the server project (use artor rm for that).

Flags combine — --skills --npmrc strips skills and the managed .npmrc block while keeping the project link. With no flags on a terminal, a checklist lets you choose (the project link is pre-checked; skills and .npmrc appear only if present). With no flags and no terminal, it removes just the project link.

Organization context

When you belong to more than one organization, commands choose the target in this order:

1. --org <ref> on the command line.
2. The organization stamped into the folder’s link by init / link.
3. Your saved default (artor org use).
4. The organization you were in when you logged in.

status and whoami report the active organization, the one commands will use, together with your role. The organization used when you logged in is shown only when it differs.

Commands that act on the linked folder use that folder’s organization. Commands that target something by reference, including remix, pull --project, restore, rm <ref>, rename <ref>, trash, and usage, also accept --org <ref>. Without it they follow the same order above, including the linked folder before the saved default.

If the active organization is stale or you are no longer a member, run artor org list, then use artor org use <ref>, pass --org <ref>, or re-point the folder with artor link --org <ref> <id|slug> --force.

Your token

Your login token is stored securely on your computer. Treat it like a password. artor logout signs out locally; revoke the token under Settings → CLI tokens to stop it working everywhere.