# Install and start with VibeCord

Updated: 2026-08-31

VibeCord accepts workload artifacts made by your existing coding agent or local
tooling. The integrated VibeCord creator is disabled by default. Use your own
agent harness to build or edit the artifact, then use VibeCord for workload
inspection, staging, preview, proof, export, and admitted hosting requests.

## Current release status

The `vibecord-ops` source package is prepared as a release candidate, including
its npm manifest, binary entry point, typed action grammar, and package README.
It has not been published. A signed public package, clean-machine installer,
and remote MCP release have not been proven or launched. Do not install the
unrelated `vc` or `vibecord` packages from a public package registry.

If you are outside the VibeCord repository, open
<https://app.vibecord.dev/> and use the human account flow. There is not yet a
supported public CLI installation command.

## Repository dogfood setup

From a VibeCord checkout:

```sh
npm run build --workspace=@vibecoord/server-ops-cli
node packages/server-ops-cli/dist/bin.js --help
node scripts/qa/check-agent-native-cli-readiness.mjs --json
```

Use the full in-repository command until the package is linked locally:

```sh
node packages/server-ops-cli/dist/bin.js auth status --json
```

When a verified package link exists, use the public command name:

```sh
vibecord-ops auth status --json
```

## Connect an existing account

The current CLI does not create a VibeCord user, accept legal terms, or create
a payment identity. In an internal environment where both MCP and PAT feature
gates are enabled, a signed-in account owner can issue a scoped operations
token through the browser handoff described in [AUTH.md](./AUTH.md).

The source candidate also contains typed `auth device start` and `auth device
poll` commands plus default-off server start/poll and signed-in decision routes.
Their migration, production configuration, release, and clean-machine journey
are not proven, so they remain source integration rather than a live public
login path.

After the token is placed in the current process environment, use a
non-echoing prompt so the value is not written literally into shell history:

```sh
export VIBECORD_API_URL="https://app.vibecord.dev"
read -rsp "VIBECORD_TOKEN: " VIBECORD_TOKEN && export VIBECORD_TOKEN && printf '\n'
vibecord-ops auth whoami --json
vibecord-ops project list --json
```

PowerShell uses the same values:

```powershell
$env:VIBECORD_API_URL = "https://app.vibecord.dev"
$secureToken = Read-Host "VIBECORD_TOKEN" -AsSecureString
$env:VIBECORD_TOKEN = [System.Net.NetworkCredential]::new("", $secureToken).Password
Remove-Variable secureToken
vibecord-ops auth whoami --json
vibecord-ops project list --json
```

Never write the token into a repository file, `.env` file, prompt, screenshot,
log, or artifact.

## First workload check

The source contract can prepare explicit project and connected-workload
creation requests without inference:

```sh
vibecord-ops project create \
  --name "Friends Project" \
  --initial-workload-kind discord_bot \
  --initial-workload-slug friends-bot \
  --dry-run --json
vibecord-ops workload create \
  --project-id <project-id> \
  --kind minecraft_java \
  --slug friends-world \
  --dry-run --json
```

`project.create` requires `initialWorkload`.
`initialWorkload.workloadSlug` is deliberately required so an agent creates a
deterministic connected-row identity; a successful response returns both
`projectId` and `projectWorkloadId`. Use `workload.create` only for an
additional connected row. These source-only requests do not prove that the
matching server handlers are deployed or publicly available.

Resolve one existing project and one concrete connected workload row before any
artifact, proof, export, or hosting action:

```sh
vibecord-ops workload readiness \
  --project-id <project-id> \
  --workload-id <project-workload-id> \
  --json
```

Use `--project-slug` or `--workload-slug` only when you intentionally supply
an exact slug. A copied UUID always belongs in the corresponding `-id` flag;
the CLI never infers identifier type from its characters.

Then inspect the local artifact without uploading it:

```sh
vibecord-ops artifact inspect --from <artifact-path> --json
```

The normal operations sequence is:

```text
readiness -> inspect -> stage -> preview -> proof -> export or admitted hosting request
```

Read [WORKLOADS.md](./WORKLOADS.md) before choosing a lane and
[RECEIPTS.md](./RECEIPTS.md) before acting on a result.

## What this client cannot do

The operations client does not generate code, run chat or inference, control an
OpenCode session, issue runtime tokens, accept raw provider credentials, or
mutate cloud providers directly. It asks the VibeCord control plane to admit or
deny a typed action for one exact workload.

Local command output and static documentation are not proof that public auth,
billing, provider capacity, or hosted launch is ready.