CLI reference

See Encrypted file uploads for file backups and exact retry journals (CLI v0.9.19+).

c6s help
c6s version
c6s mcp
c6s login --provider google
c6s whoami [--json]
c6s profile list
c6s profile default
c6s profile default set <name>
c6s --profile <name> device status
c6s device enroll
c6s vault connect
c6s item list --remote
c6s item policy <item-id> --field <label-or-id> --agent-policy <policy>
c6s request list
c6s --profile PROFILE request wait REQUEST_ID --json
c6s device setup [--json]
c6s device status [--json]
c6s protocol verify
c6s protocol inspect

Output contract

• Human output is concise and intended for a terminal.
• --json output is stable machine data where a command supports it.
• Diagnostics and usage errors use standard error.
• MCP standard output contains protocol frames only.

Trusted CLI setup

Authentication, device trust, and vault connection are separate steps:

c6s login --provider google
c6s whoami
c6s device enroll
c6s device remote-status
c6s vault connect
c6s vault remote-status

Approve the exact pending CLI device in Cerberus on a trusted iPhone before running vault connect. Account profiles are isolated. Set a convenient default for interactive use, and use --profile <name> or C6S_PROFILE for scripts instead of changing shared state before every command.

Check the current sign-in

Use c6s whoami to refresh the selected profile when necessary and verify the account against the server. It reports only value-free profile, account, organization, provider, state, expiry, and automatic-renewal metadata. Use c6s --profile <name> whoami to inspect another configured profile.

The one-hour access token renews automatically. Interactive login is normally required only after 30 days without a refresh, the 90-day absolute session limit, explicit logout or revocation, or replay detection. Network and Keychain failures are reported separately; they do not mean that the account was logged out and do not delete its credential.

Change access policy without re-entering a value

An existing field's agent-use policy is metadata. Change it without revealing or replacing the encrypted value:

c6s item policy ITEM_ID \
  --field FIELD_ID \
  --agent-policy approved_injection
c6s item inspect ITEM_ID
c6s vault upload --yes

The policy change is local until the explicit upload. reference_only is the safe default, approved_injection makes that exact field eligible for a separately approved action, and never_agent excludes it from agent use.

For an item that already exists in the connected remote vault, use the remote ID and change the policy directly against its latest encrypted revision:

c6s item policy REMOTE_ITEM_ID --remote \
  --field FIELD_ID \
  --agent-policy approved_injection

This operation preserves every field value and unrelated attribute. A concurrent writer causes a conflict and the CLI does not retry or overwrite it. Local and remote revision numbers are independent; never edit vault files or lower a revision to make them match. vault upload is not a conflict override.

If initial upload finds different content under an active hosted item, it stops before the first write and names the local ID, hosted ID, and hosted revision. Run only the two value-free item inspect commands it prints. Do not use vault reconcile: that command is limited to an unoccupied tombstone. With --json, the same failure is a vault_active_item_conflict object on standard error with writesApplied: 0, reconcileAllowed: false, and safe nextCommands; standard output remains empty.

A missing field is different: import it once from a trusted local source. Keep secret text out of command arguments, chat, logs, and temporary plaintext files:

c6s item set ITEM_ID \
  --field "Private Key" \
  --value-stdin \
  --kind private_key \
  --agent-policy never_agent < /path/to/key.p8

Use a native encrypted attachment for binary certificates or signing bundles when the consuming workflow accepts a file. Do not manually split one credential across several text fields. Promote a private key to approved_injection only when the user has deliberately accepted that exact approved-process use.

Read a current OTP code

This feature requires CLI v0.11.0+, macOS 0.7.0+, and iOS 1.0.0 (56)+ from TestFlight. Update all editing apps/CLI clients before enabling access. The owner can turn on Allow agent code reads in an authenticator's settings (older apps call this Allow CLI code reads). Existing entries remain approval-only until explicitly enabled.

c6s --profile PROFILE otp get ITEM_ID --field FIELD_ID --json

Returns the current code as a string (keep leading zeroes), expiresAt, generatedAt, remainingSeconds, periodSeconds, and exact item/field/revision. The default five-second minimum validity waits for a fresh window when necessary; --min-validity 0s returns the current code immediately. It checks online device trust and current hosted policy, including after waiting; there is no offline fallback, approval prompt, grant consumption, or child process for an allowed read.

This output is sensitive, unlike item metadata. Use it only for the intended destination while valid; do not log it or automatically retry a login/payment. The permanent setup key remains hidden with never_agent policy. A denied read is not authorization for an agent to enable access itself. Existing otp request remains available when you prefer approval-bound injection without returning a code.

Choose the right OTP workflow

What you need	How to continue
A code for an authorized input, with code reads enabled	Use otp get just before entering it; the result includes its expiry.
An exact program using an approval-only authenticator	Use otp request, then wait for app approval and execute once.
Browser typing with code reads disabled	Enable reads in 2FA → Edit, save and sync, or enter the code yourself.

A denied read does not mean OTP use is unavailable. For a program you have already authorized, approval-only use works without enabling direct reads:

c6s --profile PROFILE otp request --summary "Use this authenticator for the reviewed action" \
  --inject ITEM_ID:FIELD_ID:REVISION:ENV --json -- /absolute/program AUTHORIZED_ARGS
c6s --profile PROFILE request wait REQUEST_ID --execute --json

Use the exact hosted field and revision, executable and arguments. After approval, c6s generates a fresh code at process start and injects it into that process. It does not return a code to a separate browser automation tool. Agents should continue an already authorized process through this route rather than abandon it after a direct-read denial or ask for the same chat authorization again.

Mac 0.7.1 and iOS TestFlight 1.0.0 (57): import previews also offer the read permission, and Agent code access reviews existing accounts together. Only choices you change are saved; current permissions and setup keys are preserved. CLI v0.11.1 adds an explicit otpCodeReadAllowed flag without exposing a code.

An owner-authorized policy edit can also pin the exact reviewed hosted revision:

c6s --profile PROFILE otp policy ITEM_ID --field FIELD_ID --revision CURRENT_REVISION \
  --code-policy allow_read --yes --json

Use approval_required to revoke reads. Inspect metadata for the current revision first; a concurrent edit stops safely. Native changes take effect after sync.

Request one approved execution

First inspect remote item and field identifiers. Values remain concealed:

c6s item list --remote
c6s item inspect ITEM_ID --remote

Create an immutable request using an absolute executable and an exact item, field, and revision reference. The field must allow approved_injection:

c6s request create \
  --summary "Deploy the reviewed release" \
  --inject ITEM_ID:FIELD_ID:REVISION:API_TOKEN \
  -- /usr/bin/env deploy

After reviewing and approving the exact process in the iPhone app, consume the short-lived grant once:

c6s request inspect REQUEST_ID
c6s request execute REQUEST_ID

Execution never invokes a shell. It resolves the exact encrypted revision locally, injects eligible values only into the child environment, captures bounded output, and redacts exact injected values. Do not treat output redaction as general DLP: a child process can transform or transmit data, so approve only a known executable and arguments.

Wait for approval without losing the request

For an agent workflow, pin the same profile and keep the returned request ID. Choose one mode:

# Wait for the decision only; do not execute.
c6s --profile PROFILE request wait REQUEST_ID --json
# Or, only if the user authorized this exact action after human approval:
c6s --profile PROFILE request wait REQUEST_ID --execute --json

Inspect the exact intent before starting wait-and-execute. The first mode never fetches or consumes a grant. The second runs the approved process once; it is not agent self-approval. Both support ordinary fields, TOTP and private-file inputs.

CLI v0.11.3 defaults to 15 minutes for review and a 15-minute, one-use execution grant after signed approval. Configure either window as described below. Local waiting uses the saved approval default and accepts an explicit 1s–24h timeout; it extends neither lifetime and does not become the approved process's time limit. CLI v0.11.2 and earlier used five-minute review, two-minute execution and a 2s–10m local wait (default 5m). Existing requests retain their original limits. Keep one supervised CLI process alive; resume its execution-tool handle rather than creating another request at each yield. No webhook or automatic agent wakeup is provided.

After a local timeout or lost execution handle, inspect the same ID/profile. Stop on rejection, expiry, missing/unverifiable requests or consumed grants. Never re-create or replay an ambiguous execution automatically. state: approved alone is not executable: require grantState: available. Check the execution JSON's exitCode; a nonzero child exit still consumes the one-time grant.

CLI v0.10.6+ adds typed request_wait_* diagnostics on stderr with --json for wait failures (stdout stays empty), with nextAction and optional lastErrorCode. It stops on permanent authentication/permission/verification errors and retries only temporary status reads with bounded jittered backoff and Retry-After. Earlier stable versions support the same commands but may return plain-text wait errors. Initial profile/credential errors and errors after execution starts retain their own diagnostics rather than being relabeled as waiting failures.

The MCP adapter cannot approve or broaden a request and never reveals values. It can prepare the same immutable request and expose execution as a separately destructive tool only after a trusted device has issued the exact one-time grant.

Run c6s help from the installed version as the authoritative command list.

Configurable request windows (CLI v0.11.3+)

CLI v0.11.3, a compatible V4 approval app and the updated server default to 15 minutes for approval and 15 minutes for one execution after signed approval. Install the matching versions together; existing requests retain their original limits.

# Read effective defaults; no account or vault access is needed.
c6s request config --json
# Save defaults for future requests in this release channel.
c6s request config --approval-ttl 30m --execution-ttl 30m
# Restore both built-in 15-minute defaults.
c6s request config --reset

Use --approval-ttl 45m --execution-ttl 20m before -- on request create or otp request to override one request. Each option wins over its saved default, then the built-in 15m. Both accept whole seconds between 1s and 24h. Settings are channel-local and do not change old requests. The app shows the fixed approval deadline and execution duration before approval. Earlier apps reject V4 requests.

request wait uses the saved approval duration when --timeout is omitted; explicit --timeout accepts whole seconds 1s–24h and changes only local waiting. For a request-specific longer approval window, pass a matching wait timeout. Neither window limits how long an already started process runs. A failed start still consumes the grant; do not automatically repeat it.