Lifebase CLI

The official command-line installer and updater for Lifebase.

Lifebase CLI installs a licensed Lifebase vault, keeps it connected to the release service, applies separate update policies to product files and personal notes, and configures supported AI agents to use the skills bundled with the vault.

Run lifebase without arguments for the guided terminal experience. Direct commands and stable JSON output are also available for automation.

Visit lifebaseai.com for product information and guides in English.

Highlights

• Guided installation with license verification, release selection, and safe destination checks
• Exact-version installation from the releases available to your license
• Update planning that preserves user-owned notes and reviews customized product files
• Local connection for copied or previously installed Lifebase vaults
• System credential storage with an approved local-file fallback when it is unavailable
• Local skill setup for Hermes, OpenClaw, Codex, Claude Code, Gemini CLI, Google Antigravity, OpenCode, Cursor, GitHub Copilot, Cline, Windsurf, and Kiro
• Machine-readable output for scripts and managed environments

Requirements

• Node.js 20 or newer
• A Lifebase license, linked to your Lifebase account or available as a license key
• Internet access for sign-in, release discovery, and managed downloads
• Obsidian to open and use the installed vault

The same npm package runs on macOS, Windows, and Linux. It does not require Python, a compiler, or a separately downloaded executable.

| Platform | Secure session storage | | --- | --- | | macOS | Keychain Services | | Windows | Current-user DPAPI protection | | Linux | Secret Service through secret-tool |

No extra credential-storage software is required to get started. If the system store is unavailable on any platform, the CLI offers local-file storage. Connecting a local vault does not require authentication.

Login storage

Sign in normally with your Lifebase account or license key. The CLI tries the system credential store first. If it cannot use that store, choose Yes when asked to save your login in a local file. No additional package installation, keyring setup or keyring password is required for this fallback, including on Ubuntu over SSH.

The local file contains a revocable login session, not your license key. It is outside the vault in the CLI configuration directory, under credentials/session.json. File permissions restrict access to your user account; the file is not encrypted. Programs running as you, administrators and backups that include this directory may access it. Do not copy or sync the credentials directory with your vault.

The CLI remembers your choice on this computer. lifebase status shows the storage type. Logout removes the local session while retaining the storage choice, so an old system-store session cannot reappear. If a previous system session cannot be read, sign in again; the CLI cannot recover a token it cannot access. Previously issued sessions can be managed from your account.

For scripts or agents without an interactive terminal, add --allow-local-credentials to the sign-in command to approve this fallback. Without prior approval, the CLI returns an input_required error before server authentication. The flag permits fallback; a working system store remains the first choice. JSON output stays machine-readable.

If local file permissions cannot be established, the CLI reports that error rather than writing an exposed session. You may also decline file storage and repair the system credential store yourself. The CLI never installs packages, collects keyring passwords or restarts keyring services on your behalf.

Existing Linux keyring errors

If an older CLI asks you to install secret-tool or unlock a keyring, update the CLI to a release with local-file fallback, then sign in again. Copying a vault from another computer does not copy its login. No daemon recovery commands are required when choosing local-file storage.

Install

npm install -g @lifebase/cli
lifebase

Upgrade the CLI independently from the Lifebase vault:

npm install -g @lifebase/cli@latest

The interactive lifebase command periodically checks for a newer CLI release. When one is available, it shows the current and target versions and asks before running an update, with updating as the default choice. Declining continues only the current session, so the prompt returns on the next interactive launch. Results with an available update are cached for six hours, while an up-to-date result is refreshed after fifteen minutes. Offline checks fail silently and never block the vault menu.

Automatic updates preserve package-manager ownership:

| Installation source | Update command | | --- | --- | | npm or the current macOS/Windows bootstrap script | npm install --global @lifebase/cli@<version> | | Homebrew Formula | brew upgrade <formula> | | winget package | winget upgrade --id <package-id> | | Unknown or local installation | Notification only; use the original installer or package manager |

The current bootstrap scripts may use Homebrew or winget to provision Node.js, but they install Lifebase CLI itself through npm. Future official Homebrew and winget packages identify both their channel and exact package ID to the CLI. A channel inferred from its path is notification-only until that identity is confirmed. The updater never uses npm to overwrite files owned by another package manager. After a successful update, run lifebase again so the new code starts in a fresh process.

lifebase --version reports the CLI version. lifebase status reports the installed vault version and current license state.

Guided setup

The CLI guides you through the first installation:

Account sign-in chooses Korean (/cli-login/) or English (/en/cli-login/) from the first nonempty LC_ALL, LC_MESSAGES, or LANG value, then the system locale reported by Node. Non-Korean or unknown locales use English. This also applies to --no-browser links and account-management guidance; terminal output stays English.

1. Choose Lifebase account or License key in Sign in. Account sign-in opens the website for Google/GitHub login and connection approval, then lets you choose an owned license in the CLI. Key sign-in hides and immediately verifies the entered key.
2. Choose Documents, the current directory, or a custom absolute destination.
3. Select a content language and an authorized Lifebase release.
4. Review and accept the license terms.
5. Download, verify, and install the vault, then optionally configure an AI agent.

The recommended destination is ~/Documents/lifebase. A new installation requires a new or empty writable directory. Relative paths such as . are rejected; ~ is expanded on macOS and Linux.

Keyboard controls

| Key | Action | | --- | --- | | ↑ / ↓ | Move through a menu | | Enter | Select or confirm | | Esc | Return from the current nested prompt | | q | Quit from an arrow-key menu without signing out or disconnecting | | Ctrl+C | Exit immediately while preserving completed steps |

The CLI returns to the main menu after each completed or recoverable action. Direct subcommands run once and exit.

When the connected license can access a newer compatible Lifebase release, the CLI shows the current and newest versions, moves Update to the top of the menu, and marks it Recommended. Without an available update, the normal Status-first menu order is preserved.

Common commands

| Task | Command | | --- | --- | | Open the guided interface | lifebase | | Show license and vault status | lifebase status | | List currently supported releases | lifebase releases | | Include support-ended releases | lifebase releases --include-legacy | | Install Lifebase in English | lifebase install --path ~/Documents/lifebase --locale en | | Install Lifebase in Korean | lifebase install --path ~/Documents/lifebase --locale ko | | Install an exact authorized version | lifebase install --path ~/Documents/lifebase --locale ko --version 0.4.0 | | Update the connected vault | lifebase update | | Connect an existing vault | lifebase link --vault /absolute/path/to/lifebase | | Sign in with a Lifebase account | lifebase login | | Show the browser address and code without opening a browser | lifebase login --no-browser | | Sign in with a license key | lifebase activate | | Sign out while keeping the vault | lifebase logout | | Preview Hermes configuration | lifebase agent setup --tool hermes --dry-run | | Configure an agent | lifebase agent setup --tool hermes | | Show all commands | lifebase --help |

Add --help to any command for its complete option list.

Releases and version selection

The release catalog is filtered by license access, content language, CLI compatibility, and release support status. One license covers its authorized product versions in both languages.

From product 0.3.0, the ZIP name includes the content language (Lifebase-0.3.0-en.zip or Lifebase-0.3.0-ko.zip), and .lifebase-state.json records the same locale. The CLI checks this metadata before installing and compares the installed, base, and target languages before preparing an update. Korean releases before 0.3.0 retain support for their original ZIP names and state files without a locale field.

• Latest available is the newest exact release currently available to your license. It is not a moving channel alias.
• Pre-release identifies a prerelease explicitly.
• Versions requiring a newer CLI are shown as unavailable until the CLI is upgraded.
• The Update menu contains only releases newer than the installed vault.
• lifebase releases --include-legacy adds support-ended releases that remain downloadable under the current license.

Without --version, install and update request the latest eligible release. A new installation defaults to ko; pass --locale en for English or select English during interactive installation. An update uses the content language recorded in the local vault state. --locale may confirm that language but cannot change it. To use another language, install it into a separate vault; ordinary updates do not translate existing notes, paths, or links.

An update never performs an in-place downgrade. To use an older authorized version, install it into a different new or empty directory and move personal content deliberately.

Connect an existing vault

Use local connection when Lifebase was copied from another device, the CLI was reinstalled, or the saved path was lost:

lifebase link --vault ~/Documents/lifebase

The directory must contain valid .lifebase-version and .lifebase-state.json metadata. Linking validates and remembers the path without reinstalling files, changing agent settings, or contacting the license service. The CLI manages one connected vault path per local configuration.

The CLI can discover Lifebase in ~/Documents/lifebase, the current directory, or its lifebase child. It does not scan the entire disk.

If a connected folder was moved, use Locate the vault in the main menu or run link with its new absolute path. If the folder was deleted, restore a backup or disconnect it in the main menu before installing a new vault.

Update safely

Run lifebase and choose Update, or use:

lifebase update

For human-readable use, the command shows the current and target versions and asks for confirmation before downloading. update is not a check-only command.

Lifebase updates distinguish between product-managed files and user-owned content:

• unchanged product files can advance automatically;
• locally customized product files are prepared for review;
• user-owned notes are not silently replaced;
• changed files receive a rollback backup before finalization;
• the installed version advances only after the update transaction completes.

When review is required, the CLI shows one compact conflict list before changing the vault. Move between files with Up and Down. A fixed decision bar below the list keeps Keep local, Merge required, Use edited result, and Use release visible while Left and Right change the selected outcome. The edited-result choice stays visibly disabled until a draft exists, so the list does not shift as you move between files. Every regular-file conflict starts at Merge required. Press D to open a scrollable three-way diff for the selected file. The default Combined view groups competing results around the same Base passage: Base removals are labeled in red, Mine in cyan, Release in green, and a saved Draft in amber. The labels remain visible without color. Number keys switch to Combined, Mine, Release, or Draft views for closer inspection. Long diffs show the active view, line range, and view-local change count; N/P jump between changed groups and Page Up/Page Down move by screen. Press E to create or resume an edited draft in the updater workspace using VISUAL, EDITOR, or the platform editor. The vault file itself is not opened for editing.

An edited draft remains Merge required · Draft saved until Use edited result is chosen explicitly. Returning it to Merge required preserves the draft for later work; R resets only that saved draft after confirmation and leaves Base, Local, Target, and the vault untouched. Finalization still refuses every unresolved item. L, M, and T apply Keep local, Merge required, or Use release to every eligible item. Protected paths explain why they cannot be replaced, for example Keep local · Symlink, Keep local · Linked parent, or Keep local · Directory. Reopening a pending update whose decisions are already resolved still shows the complete review list; the update is applied only after Enter is pressed there. Otherwise the CLI preserves the pending handoff and shows the exact phrase to enter in an agent. Its English fallback is:

resume lifebase update

The displayed request follows the installed content locale: Korean uses Lifebase 업데이트 마저 해줘, English uses resume lifebase update, and locales without translated copy fall back to the same short English request. When the lifebase-update package differs between the installed Base release and Target release, the prompt keeps that request first and adds the staged target SKILL.md path. The CLI compares the complete package, including references, and copies it into the protected handoff workspace only when agent review is also needed. The installed copy advances only during successful finalization.

The interactive list intentionally keeps other long internal paths out of the human UI. The effective target lifebase-update skill queries unresolved items through JSON, resolves its staged bootstrap and each Base, Local, Target, and Merged path relative to the returned workspace, creates reviewed merge results, records decisions through the CLI, and finalizes transactionally. Humans and agents never need to edit updater JSON:

lifebase update review --vault ~/Documents/lifebase
lifebase update review --vault ~/Documents/lifebase --unresolved-only --json --non-interactive
lifebase update diff --vault ~/Documents/lifebase AGENTS.md
lifebase update edit --vault ~/Documents/lifebase AGENTS.md
lifebase update reset-draft --vault ~/Documents/lifebase --yes AGENTS.md
lifebase update decide --vault ~/Documents/lifebase --decision keep-local AGENTS.md "Journal/example.md" "Knowledge/Guide.md"
lifebase update decide --vault ~/Documents/lifebase --decision use-target AGENTS.md
lifebase update decide --vault ~/Documents/lifebase --decision use-merged AGENTS.md
lifebase update decide --vault ~/Documents/lifebase --decision merge-required AGENTS.md
lifebase update finalize --vault ~/Documents/lifebase
lifebase update cancel --vault ~/Documents/lifebase

Decisions start unresolved. Finalization is blocked until every conflict has an explicit keep, replace, or reviewed edited result. One update decide command accepts any number of paths with the same decision, so an agent can normally record a large review in at most three grouped commands after preparing any merged files. merge-required clears a recorded result without deleting its draft; reset-draft deliberately deletes one draft and clears the decision only when it depended on that edited result. Existing Local or Target decisions remain valid. Starting another update cannot overwrite an existing handoff; resume it or explicitly cancel and rebuild it. Cancelling removes the updater-owned workspace and any saved drafts after confirmation.

A release may also include follow-up guidance for work that cannot be completed safely by changing files in the current vault, such as refreshing a device-local setting elsewhere. The CLI selects guides introduced after the installed version and at or before the target version, including guides from skipped releases. It shows them while an update is pending and again after apply. A successful vault transaction can therefore report both completed: true and follow_up_required: true; complete the listed required steps before treating the broader migration as finished.

Configure AI agents

Agent setup grants a supported local agent access to the skills already included in the connected vault. It does not install an AI agent, sign in to an agent account, invoke a model, or upload vault content.

Interactive agent setup lists the portable skills it found, then shows every detected agent in one hierarchical checklist. Detected agents start selected. Hermes includes a selected Use Lifebase as the default path for Hermes Gateway option; OpenClaw includes an unselected Move Lifebase into the OpenClaw workspace option because that choice relocates the vault. Use Up and Down to navigate, Space to toggle, Enter to apply, and Esc to return without changes. Unselect every agent and press Enter to skip setup. A direct child is treated as a skill only when its readable SKILL.md has valid YAML frontmatter, a directory-matching name, and a non-empty description. Unrelated or malformed runtime directories are ignored.

lifebase agent status --tool hermes
lifebase agent setup --tool hermes --dry-run
lifebase agent setup --tool hermes
lifebase agent setup --tool hermes --set-vault-working-directory
lifebase agent setup --tool openclaw --dry-run
lifebase agent setup --tool openclaw
lifebase agent setup --tool openclaw --move-vault-to-workspace --dry-run --json --non-interactive
lifebase agent setup --tool openclaw --move-vault-to-workspace --yes
lifebase agent setup --tool codex
lifebase agent setup --tool claude
lifebase agent setup --tool gemini
lifebase agent setup --tool antigravity
lifebase agent setup --tool opencode
lifebase agent setup --tool cursor
lifebase agent setup --tool copilot
lifebase agent setup --tool cline
lifebase agent setup --tool windsurf
lifebase agent setup --tool kiro

Hermes setup adds the vault's .agents/skills directory to its configuration. Interactive setup also selects the option to set terminal.cwd to the vault so Hermes Gateway starts from Lifebase; uncheck it to keep the existing working directory. Direct commands change the working directory only when --set-vault-working-directory is present. Use --dry-run to inspect the proposed change. Existing unrelated YAML content is preserved as far as the parser can round-trip it, a backup is created, and repeated setup does not add duplicate paths.

OpenClaw setup registers .agents/skills under skills.load.extraDirs in the active openclaw.json. The optional workspace checkbox physically moves the whole vault to <OpenClaw workspace>/<vault name>, updates the connected Lifebase path, replaces the old skill registration, and leaves the vault there if the OpenClaw registration is removed later. It is off by default. A move is refused while a Lifebase update is pending, when the destination already exists, or when an atomic same-filesystem rename is not possible. Configuration or path-record failures trigger rollback to the original location. Direct non-interactive moves require both --move-vault-to-workspace and --yes; --dry-run --json --non-interactive reports the source, destination, workspace, availability, and config diff without writing.

The CLI asks OpenClaw itself to dry-run, validate, and write configuration changes instead of parsing or replacing its JSON5 configuration. The active file follows OPENCLAW_CONFIG_PATH or OpenClaw's default; pass --config to select a specific regular config file. Repeated setup is idempotent, and agent remove --tool openclaw removes only the exact current Lifebase skill path. Explicit OpenClaw per-agent skill allowlists are permission choices and are never widened automatically; when such an allowlist exists, add only the Lifebase skills that agent should see.

Codex, Google Antigravity, OpenCode, Cursor, GitHub Copilot, and Windsurf discover project skills directly from the canonical <vault>/.agents/skills tree. Setup verifies that tree without changing global configuration. Open or trust the Lifebase vault as the agent's working project so the tool can discover its project-local skills.

Claude Code setup creates <vault>/CLAUDE.md with a single @AGENTS.md import and one project-local .claude/skills/<name> directory link per Lifebase skill. Cline receives the equivalent links under .cline/skills, its recommended project path; enable Cline's Skills feature if that experimental feature is still disabled in your installation. Kiro receives links under .kiro/skills. The release ZIP contains none of these tool-specific adapters: setup derives them from the canonical files only for selected tools. Existing unrelated skills are preserved, name collisions stop setup instead of being overwritten, repeated setup repairs missing managed links, and removal deletes only Lifebase-managed links. An OpenClaw vault move repairs these links at the new path.

Gemini CLI setup creates <vault>/GEMINI.md with the same single @AGENTS.md import, so Gemini receives the canonical vault instructions without maintaining a second rules document. Existing CLAUDE.md and GEMINI.md files are never overwritten: setup accepts one that already imports AGENTS.md and otherwise asks you to add the import manually. Removal deletes only an untouched one-line adapter created by Lifebase and preserves customized context files.

For a nonstandard Hermes or OpenClaw configuration path:

lifebase agent setup --tool hermes --config /absolute/path/to/config.yaml --dry-run
lifebase agent setup --tool openclaw --config /absolute/path/to/openclaw.json --dry-run

License sessions and local state

The CLI never stores the license key. After verification, it stores only a revocable login session, separately from the vault, using the operating system credential store or the local-file fallback you approved. On macOS, the item is labeled Lifebase CLI login session; Lifebase does not request access to unrelated Keychain items.

Account sign-in displays a ten-minute connection code. You can approve it in a browser on another device, including when the CLI runs through SSH or Docker. Match the code and device before approving. Only the selected license session is saved; the temporary account token stays in memory. An account with no usable linked licenses is directed to the website to register or manage one. Existing key-based activation remains available.

Change license offers the same two sign-in methods. Cancelling or failing authentication keeps the current session. After the new session is saved, the previous bearer is revoked; if that cleanup cannot reach the server, the CLI reports it. Unlinking a license or deleting its account ends sessions issued through that account; direct-key sessions remain independent. Website logout ends pending approvals, while an already activated CLI session remains signed in.

The connected vault path and a random installation ID are stored in the current user's application configuration directory. Release archives and update working material use the operating system cache directory. Reinstalling the npm package does not necessarily remove this local state.

These actions have intentionally different scopes:

| Action | Authentication | Connected path | Vault files | Server device slot | | --- | --- | --- | --- | --- | | lifebase logout | Cleared | Kept | Kept | Deactivated | | Disconnect this vault | Kept | Cleared | Kept | Kept | | lifebase device deactivate --device-id current | Cleared | Cleared | Kept | Deactivated |

To switch licenses, use Change license in the main menu or run:

lifebase logout
lifebase activate

If normal logout cannot reach the server, it keeps the local session so the operation can be retried. lifebase logout --local explicitly clears only local authentication; it does not revoke the server session or free the device slot.

Automation and JSON output

Use an explicit command with both --json and --non-interactive:

lifebase status --json --non-interactive
lifebase releases --json --non-interactive
lifebase install --path /absolute/path/to/lifebase --locale ko --version 0.4.0 --accept-terms --json --non-interactive
lifebase update --json --non-interactive
lifebase update review --unresolved-only --json --non-interactive
lifebase agent setup --tool hermes --dry-run --json --non-interactive

JSON results are written to stdout and JSON errors to stderr. They do not include ANSI styling, spinners, or explanatory terminal text. Calling bare lifebase with automation flags does not open the interactive menu and returns an input-required error.

lifebase update --json --non-interactive returns a compact state summary: status, whether the command completed, whether the vault changed, base and target versions, automatic-change and review counts, unresolved items, update_guidance, follow_up_required, and a structured next_action. It does not expose internal plan, decision, manifest, or pending-pointer JSON paths. A normal action uses command: "lifebase" and a complete arguments array. When the update skill package changed and review is needed, the optional agent_bootstrap names the target release's staged skill, next_action.action is read_update_skill, and next_action.then holds the ordinary CLI action to perform after reading it. When the package is unchanged, agent_bootstrap is omitted and preparation points directly to update review; detailed review points to update decide and declares its required decision and paths; a recorded decision points to another review while work remains or to update finalize when it is ready. Review items report draft_saved separately from decision, so a saved partial edit never implies approval. lifebase status --json --non-interactive exposes the same compact state under pending_update, so a later agent can resume without rediscovering internal files. Guidance verification entries are declarative data and must never be executed as commands. Agents should follow these CLI responses rather than opening or editing updater-owned JSON files.

lifebase login needs an interactive terminal and browser approval. --json or --non-interactive returns input_required without starting an approval; use key-based activate for unattended activation.

For unattended activation, provide LIFEBASE_LICENSE_KEY through a secret manager or send the key on stdin. Avoid literal keys in command arguments, shell history, logs, and checked-in files. --accept-terms should be used only after the current terms have been reviewed.

| Exit code | Meaning | | --- | --- | | 0 | Command completed; inspect update results for pending review | | 2 | Invalid usage or required input is missing | | 3 | Authentication, license, or entitlement failure | | 4 | Network, API, service, or credential-store failure | | 5 | Installation or release archive verification failure | | 6 | Agent setup or update handoff failure | | 10 | Unexpected internal error | | 130 | Cancelled with Ctrl+C |

For AI agents

When operating Lifebase on a user's behalf:

1. Read the connected vault's AGENTS.md and any task-specific skill before changing files. Vault instructions take precedence over this package overview.
2. Use lifebase status --json --non-interactive to inspect CLI, license, connected-vault, and pending-update state without scraping terminal formatting.
3. Use the CLI for installation, connection, release discovery, and update transactions. Do not edit .lifebase-version, .lifebase-state.json, or .lifebase-update-pending.json to bypass validation.
4. Treat Journal entries, Tasks, Profile data, attachments, and other personal notes as user-owned content. Do not overwrite, relocate, upload, or summarize them beyond the user's request.
5. When an update requires review, inspect whether agent_bootstrap exists. If present, read the workspace-relative target SKILL.md and use that staged package for this update; do not copy it into the vault. If absent, continue directly with next_action. Then query lifebase update review --unresolved-only --json --non-interactive, write only explicit merged results to the returned paths, and record every choice with lifebase update decide --vault ...; do not parse or edit updater JSON directly. Use merge-required to withdraw a decision while retaining an unfinished draft.
6. Do not request, echo, or reproduce license keys in model conversations, logs, command arguments, generated files, or commits. Hand control to the user at the hidden terminal prompt, reuse an existing session, or use a user-managed secret channel.

The CLI's JSON interface is the integration contract for agents and automation. Human-facing colors, prompts, menu layout, and interactive CLI-update reminders are not stable parsing targets. Explicit commands using --json --non-interactive never run the startup update prompt.

Install from an existing release archive

An already downloaded archive can be installed after verifying its expected SHA-256 digest:

lifebase install \
  --artifact-path /absolute/path/to/Lifebase.zip \
  --sha256 '<64-character-sha256>' \
  --path ~/Documents/lifebase \
  --locale ko \
  --accept-terms

Local archive installation still requires a valid license session and server confirmation. It is not an offline authentication bypass. Avoid --overwrite for a vault containing personal data: it replaces an entire verified Lifebase directory rather than applying the normal update policy.

Privacy and security

The interactive CLI periodically requests the public npm metadata for @lifebase/cli to check its latest version. This request contains no Lifebase license key, session token, vault path, or vault content.

Activation sends the license key, product identifier, random installation ID, device name, and platform to the licensing service. Release and vault-update operations send the information needed to authorize downloads and confirm the installed version.

The CLI does not send the vault path, note names, note contents, local file hashes, diffs, update merge material, or AI prompts to the licensing service. License keys and session tokens are never written into the vault.

Only direct the CLI to the official Lifebase service. If using the advanced --api-url option, send credentials only to an endpoint you control and trust.

Troubleshooting

| Problem | Resolution | | --- | --- | | Session is missing or expired | Run lifebase login for account sign-in, or lifebase activate to use a license key | | A different license should be used | Choose Change license in lifebase to sign in with another account or key; unset any old LIFEBASE_LICENSE_KEY value | | Logout cannot reach the server | Retry when connected, or use logout --local while accepting that the server device slot remains active | | System credential store is unavailable | Accept local file storage during sign-in, or approve it with --allow-local-credentials for unattended sign-in | | Installation destination is rejected | Choose a new or empty writable absolute path; use link for an existing Lifebase vault | | Connected folder cannot be found | Locate the moved folder in the main menu, reconnect it with link, or disconnect the missing path | | A release is unavailable | Check the selected locale, license coverage, support status, and required CLI version | | Update prepared but the version did not change | Follow the CLI's displayed AI-agent prompt; it reads a staged target update skill first when required, then resumes review | | An agent is not detected | Install the agent separately, ensure its executable is on PATH, and run lifebase agent status --tool <tool> | | Automatic CLI update fails | Run the exact command displayed by the CLI, or update with the package manager that originally installed it |

For command-specific help:

lifebase <command> --help

License

Use of Lifebase CLI and the Lifebase product is governed by the license included with this package.