Reference for the kimbap CLI. Covers the most commonly used commands and their flags.
Print the CLI version. Release builds show the tagged version, and may also include build metadata like commit/date.
Example:
kimbap --versionExecute a registered action.
Flags are derived from the action's input schema. Each flag corresponds to an input field defined in the service manifest. Required fields without defaults must be provided.
Syntax:
kimbap call <service>.<action> [--<arg> <value> ...]
Examples:
kimbap call github.list-repos --sort updated
kimbap call github.create-issue --owner acme --repo api --title "fix bug" --body "details"
kimbap call slack.post-message --channel C123 --text "hello"Create a standalone shortcut command (no kimbap call prefix needed at runtime).
Many catalog services are installed with default shortcuts automatically; use this when you want to add or override one manually.
Syntax:
kimbap alias set <shortcut> <service>.<action>
Examples:
kimbap alias set geosearch open-meteo-geocoding.search
geosearch --name "San Francisco"To remove it:
kimbap alias remove geosearchSearch installed actions by keyword or description. Matches against action names, descriptions, and service names.
Syntax:
kimbap search <query>
Examples:
kimbap search "send message"
kimbap search "list repos"
kimbap search refundList all installed actions across all services.
Flags:
| Flag | Description |
|---|---|
--service <name> |
Filter results to a single service |
Examples:
kimbap actions list
kimbap actions list --service github
kimbap actions list --service stripeShow the full schema for an action, including input field types, required fields, auth requirements, and risk level.
Syntax:
kimbap actions describe <service>.<action>
Example:
kimbap actions describe stripe.list-charges
kimbap actions describe github.create-issueInstall a service manifest. Accepts a path to a local YAML file, an HTTPS URL, or a catalog service name from the service catalog.
Syntax:
kimbap service install <name|path-to-yaml|url> [--force] [--no-shortcuts]
Examples:
kimbap service install github
kimbap service install my-service.yaml
kimbap service install https://example.com/service.yaml
kimbap service install stripe
kimbap service install github --force
kimbap service install github --no-shortcutsInstall sets up eligible shortcut aliases by default. Use --no-shortcuts to skip.
Generate a service manifest from an OpenAPI 3.x spec.
Remote OpenAPI URLs must use https://. Plain http:// is allowed only for localhost/loopback sources such as http://127.0.0.1:8080/openapi.yaml.
When --openapi points at a local file, relative file $ref patterns such as ./schemas/pet.yaml#/Pet are supported, including nested refs across split-file specs. Remote URL sources do not resolve external ref trees.
Syntax:
kimbap service generate --openapi <path-or-url> [--name <service>] [--tag <tag> ...] [--path-prefix <prefix> ...] [--output file.yaml] [--install]
Flags:
| Flag | Description |
|---|---|
--openapi <path-or-url> |
OpenAPI 3.x spec file path or URL |
--name <service> |
Override the generated service name |
--tag <tag> |
Include only operations with a matching OpenAPI tag. Repeatable |
--path-prefix <prefix> |
Include only operations whose path starts with the given prefix. Repeatable |
--output <file> |
Write the generated YAML to a file instead of stdout |
--install |
Install the generated manifest immediately after generation |
Examples:
kimbap service generate --openapi ./openapi.yaml
kimbap service generate --openapi ./openapi.yaml --output my-service.yaml # split-file refs supported for local files
kimbap service generate --openapi https://api.example.com/openapi.yaml --output my-service.yaml
kimbap service generate --openapi http://127.0.0.1:8080/openapi.yaml --name local-api --install
kimbap service generate --openapi ./openapi.yaml --tag admin --path-prefix /v1/admin --output admin-api.yamlWhen --install is set, the command installs the manifest instead of printing YAML. In text mode it prints an install success message; in JSON mode it returns a structured install payload.
Parse and validate a service manifest without installing it. Reports all errors found, not just the first.
Catches:
- Schema errors and unknown fields
- Invalid or missing
base_url - Missing required top-level fields
- Duplicate argument names within an action
- Type mismatches in argument definitions
- Invalid risk level values
Syntax:
kimbap service validate <file>
Example:
kimbap service validate my-service.yamlList installed services, or list all catalog services with install/enable status.
Output includes shortcut aliases per service in both text (SHORTCUTS column) and JSON (shortcuts field).
With --available, JSON output also includes catalog metadata such as description, adapter, actions, auth_required, and triggers.
Syntax:
kimbap service list [--available]
Flags:
| Flag | Description |
|---|---|
--available |
List all catalog services and show whether each one is installed/enabled |
Example:
kimbap service list
kimbap service list --availableSearch built-in catalog services before installation. Matches against service names, descriptions, trigger metadata, and action names/descriptions.
Syntax:
kimbap service search <query> [--limit N]
Flags:
| Flag | Description |
|---|---|
--limit <n> |
Maximum number of matches to return. 0 means no limit |
Examples:
kimbap service search github
kimbap service search "issue management"
kimbap service search geocoding --limit 5Describe a built-in catalog service before installation. Shows adapter type, auth summary, trigger metadata, action summaries, gotchas, recipes, and install status.
Syntax:
kimbap service describe <name>
Examples:
kimbap service describe github
kimbap service describe open-meteo-geocodingList installed services that are behind the current version in the service catalog.
Syntax:
kimbap service outdated
Example:
kimbap service outdatedExport a SKILL.md file for a given service to stdout. This file is formatted for AI agent consumption and describes available actions, input schemas, and usage examples.
Syntax:
kimbap service export-agent-skill <name>
Example:
kimbap service export-agent-skill github
kimbap service export-agent-skill stripe > ./skills/stripe.mdkimbap link <service> is the recommended way to connect a service. It handles both API key storage and OAuth flows. Use vault set and auth connect for advanced or scripted scenarios.
Store a secret in the encrypted vault. Secrets are never accepted as inline CLI arguments to avoid shell history exposure.
Flags:
| Flag | Description |
|---|---|
--stdin |
Read the secret value from stdin |
--file <path> |
Read the secret value from a file |
Examples:
printf '%s' "$TOKEN" | kimbap vault set github.token --stdin
kimbap vault set stripe.api_key --file ./key.txtList vault key metadata: names, last-used timestamps, and last-rotated timestamps. Secret values are never shown.
Example:
kimbap vault listRotate a stored credential. Prompts for the new value via stdin or --file.
Syntax:
kimbap vault rotate <key>
Example:
printf '%s' "$NEW_TOKEN" | kimbap vault rotate github.token --stdinLink a service to vault credentials or an OAuth connector. Kimbap will look up the correct vault keys or connector tokens when executing actions for that service.
Use --stdin or --file to supply a credential inline during the link step, skipping a separate vault set call.
Syntax:
kimbap link <service> [--stdin | --file <path>]
Flags:
| Flag | Description |
|---|---|
--stdin |
Read the credential value from stdin during linking |
--file <path> |
Read the credential value from a file during linking |
Examples:
kimbap link github
kimbap link stripe
printf '%s' "$GITHUB_TOKEN" | kimbap link github --stdin
kimbap link stripe --file ./stripe-key.txtShow connector health and token state for all linked providers. Includes expiry status and whether the token is valid.
Example:
kimbap auth listShow connector health and token state.
- With a
providerargument: show one provider. - Without a
providerargument: show all providers.
Syntax:
kimbap auth status
kimbap auth status <provider>Example:
kimbap auth status notion
kimbap auth status slackList all bundled OAuth providers available in the built-in registry.
Example:
kimbap auth providers listAuthenticate with an OAuth provider. Starts the appropriate flow (device code or browser redirect) and persists the resulting token.
Bundled providers: canva, canvas, figma, notion, slack, stripe, zendesk, zoom.
Syntax:
kimbap auth connect <provider>
Example:
kimbap auth connect slack
kimbap auth connect notionRevoke an active OAuth session and remove the stored token for that provider.
Syntax:
kimbap auth revoke <provider>
Example:
kimbap auth revoke github
kimbap auth revoke slackLoad a policy document from a YAML file. Replaces the active policy entirely.
Syntax:
kimbap policy set --file <path>
Example:
kimbap policy set --file ./policy.yamlExample policy document:
version: "1.0.0"
rules:
- id: allow-github-read
priority: 10
match:
agents: [repo-bot]
actions: [github.list-repos, github.list-pull-requests]
decision: allow
- id: approve-stripe-refunds
priority: 20
match:
agents: [billing-bot]
actions: [stripe.create-refund]
decision: require_approval
- id: deny-destructive
priority: 5
match:
risk: critical
decision: denyPolicy decisions:
| Decision | Behavior |
|---|---|
allow |
Action proceeds immediately |
deny |
Action is blocked and returns an error |
require_approval |
Action is held until a human approves it |
Match fields:
| Field | Description |
|---|---|
agents |
List of agent identifiers. Supports glob patterns. |
services |
List of service names. Supports glob patterns. |
actions |
List of service.action identifiers. Supports glob patterns. |
risk |
Risk level: low, medium, high, or critical |
Rules are evaluated in ascending priority order. The first matching rule wins.
Print the active policy document to stdout.
Example:
kimbap policy getList all pending approval requests with their IDs, action names, requesting agents, and creation times.
Example:
kimbap approve listApprove a held action, allowing it to proceed.
Expired approvals and already-resolved approvals return distinct error codes so callers can distinguish between the two cases.
Syntax:
kimbap approve accept <id>
Example:
kimbap approve accept req_01HX...Show a recent snapshot of audit log entries (non-streaming). Error messages in audit records are capped at 256 characters.
Example:
kimbap audit tailExport audit records for a required date range as newline-delimited JSON (or CSV).
Syntax:
kimbap audit export --from <date> --to <date> [--format jsonl|csv]Accepted date formats for --from / --to: RFC3339 or YYYY-MM-DD.
Example:
kimbap audit export --from 2026-03-01 --to 2026-03-31
kimbap audit export --from 2026-03-01 --to 2026-03-31 --format csv > audit-202603.csvRun an agent subprocess inside a Kimbap-controlled environment. The subprocess gets no direct access to vault secrets. Credentials are injected server-side by the proxy or daemon, not passed through environment variables or files.
Syntax:
kimbap run -- <command> [args...]
Example:
kimbap run -- python agent.py
kimbap run -- node ./agent/index.jsStart an HTTP/HTTPS proxy that intercepts outbound requests, classifies them against installed action patterns, and injects credentials server-side before forwarding.
Route matching uses specificity-based priority: exact paths take precedence over parameterized paths, which take precedence over wildcard patterns.
Default listen address is 127.0.0.1:7788 (configurable via proxy_addr in config, or KIMBAP_PROXY_ADDR).
Example:
kimbap proxyThen in the agent's environment:
export HTTPS_PROXY=http://127.0.0.1:7788
python agent.pyStart a persistent HTTP server that exposes the action runtime over a local HTTP API.
Flags:
| Flag | Default | Description |
|---|---|---|
--addr |
config/default | API listen address override (e.g. 127.0.0.1:8080) |
--port |
0 (disabled) |
Port override; when omitted, address comes from config/default |
--console |
disabled | Enable the embedded operations console at /console |
The /console route is disabled by default. Enable it via --console flag or by setting console.enabled: true in your resolved config path ($XDG_CONFIG_HOME/kimbap/config.yaml or ~/.kimbap/config.yaml). Do not expose this endpoint on a network interface in production.
Examples:
kimbap serve
kimbap serve --addr 127.0.0.1:8080
kimbap serve --port 9000 --consoleStart a persistent runtime daemon that keeps the execution pipeline warm to avoid cold-start overhead on every kimbap call. Exposes /call, /health, and /shutdown endpoints over a Unix domain socket.
Example:
kimbap daemonInstall global Kimbap discovery hints for detected AI agent environments.
Supported agent kinds: claude-code, opencode, codex, cursor, openclaw, nanoclaw.
- Default: installs global hints only.
- Use
--sync --dir <path>to also run service sync into a project directory. - With
--with-profiles: also installs project-level operating rules files.
Example:
kimbap agents setup
kimbap agents setup --sync --dir .
kimbap agents setup --with-profilesSync installed services to detected agent skill directories. Generates a SKILL.md file per service in each discovered agent directory.
Use --agent to scope sync to specific kinds: claude-code, opencode, codex, cursor, openclaw, nanoclaw, generic.
Example:
kimbap agents sync
kimbap agents sync --agent openclaw --dir "$HOME/.openclaw/workspace"
kimbap agents sync --agent nanoclaw --dir /path/to/nanoclawShow the sync status for all known AI agent environments: which agents were detected, which skill files exist, and which are stale.
Includes Cursor, OpenClaw, and NanoClaw when their environments are present.
Example:
kimbap agents statusInstall global discovery hints and agent operating profiles. Writes a KIMBAP_OPERATING_RULES.md file into the target project directory (default .) under agent-specific subfolders.
Profiles installed per agent:
| Agent | Install location |
|---|---|
claude-code |
.claude/KIMBAP_OPERATING_RULES.md |
opencode |
.opencode/KIMBAP_OPERATING_RULES.md |
cursor |
.cursor/KIMBAP_OPERATING_RULES.md |
openclaw |
KIMBAP_OPERATING_RULES.md (OpenClaw workspace root) |
nanoclaw |
.claude/KIMBAP_OPERATING_RULES.md |
codex |
.codex/KIMBAP_OPERATING_RULES.md |
Example:
kimbap agents setup --with-profiles
kimbap agents setup --with-profiles --profile-dir /path/to/projectNote: generic is supported in kimbap agents sync (project-level sync), not in kimbap agents setup.
Generate TypeScript input interfaces for installed actions.
Flags:
| Flag | Description |
|---|---|
--service <name> |
Limit output to a single service |
-o <path> |
Write output to a file instead of stdout |
Examples:
kimbap generate ts
kimbap generate ts --service github -o ./types/github.ts
kimbap generate ts --service stripe -o ./types/stripe.tsGenerate Python TypedDict input types for installed actions.
Flags:
| Flag | Description |
|---|---|
--service <name> |
Limit output to a single service |
-o <path> |
Write output to a file instead of stdout |
Examples:
kimbap generate py
kimbap generate py --service stripe -o ./types/stripe.py
kimbap generate py --service github -o ./types/github.pyThe following commands are intended for advanced use cases.
Manage agent access tokens. Use kimbap token --help for full usage.
Generate shell completion scripts. Use kimbap completion --help for full usage.
Bootstrap a fresh Kimbap installation. Creates the data directory, initializes the vault, and optionally installs services.
In dev mode (--mode dev), a vault master key is auto-generated. In production, set KIMBAP_MASTER_KEY_HEX before running init.
Flags:
| Flag | Description |
|---|---|
--mode <mode> |
Runtime mode: dev, embedded, or connected |
--services <list> |
Comma-separated catalog service names, or all, recommended (legacy alias: starter), select |
--no-services |
Skip service installation entirely |
--no-shortcuts |
Skip automatic shortcut alias setup during init service installation |
--with-console |
Enable the /console route in the generated config |
--with-agents |
Run agents setup and agents sync after init (current directory by default) |
--agents-project-dir <path> |
Override project directory for agent sync |
--force |
Overwrite an existing config file |
Examples:
kimbap init --services select
kimbap init --services recommended --with-agents
kimbap init --services all --with-agents --agents-project-dir /path/to/project
kimbap init --services github,stripe --force
kimbap init --no-servicesService lifecycle commands (service install, enable, disable, remove, update) also attempt automatic agent sync for the current project when agent configs are detected in text output mode. Use kimbap agents sync --dir <path> for explicit sync targeting, and for JSON output workflows.
Run environment diagnostics. Checks configuration file, data directory, vault status, services directory, and policy file. Reports pass/fail for each check with actionable error messages.
Example:
kimbap doctorConfiguration is read from environment variables or discovered config file ($XDG_CONFIG_HOME/kimbap/config.yaml when set, otherwise ~/.kimbap/config.yaml). Environment variables take precedence over the config file.
| Variable | Default | Description |
|---|---|---|
KIMBAP_DATA_DIR |
~/.kimbap |
Data directory for the database, vault, and audit logs |
KIMBAP_MASTER_KEY_HEX |
auto-generated in dev mode | Hex-encoded 32-byte vault master key |
KIMBAP_DEV |
false |
Dev mode: relaxed security checks and verbose logging |
KIMBAP_DATABASE_DRIVER |
sqlite |
Database driver: sqlite or postgres |
KIMBAP_DATABASE_DSN |
$KIMBAP_DATA_DIR/kimbap.db |
Database connection string |
KIMBAP_LOG_LEVEL |
info |
Log verbosity: trace, debug, info, warn, error |
Risk levels are declared per-action in service manifests. Policy rules can match on risk level to apply blanket decisions across action categories.
| Level | Meaning | Approval hint |
|---|---|---|
low |
Read-only, no side effects, fully reversible | Auto-approve suggested |
medium |
Writes data, limited blast radius | Auto-approve suggested |
high |
Destructive or financially significant | Policy-dependent |
critical |
Irreversible or high blast radius | Approval recommended |
Approval hints are suggestions to the policy engine. Active policy rules always take precedence.