---
title: Vibecodr CLI | Vibecodr Docs
description: Install @vibecodr/cli to check web pages, run Agent Browser and Sandbox tasks, crawl public pages, save proof, approve access with vibecodr start, and track the tool credits in your plan.
canonical: https://vibecodr.space/docs/vc-tools
---

# Vibecodr CLI

Install the Vibecodr CLI and you get one command, `vibecodr`, for doing web work safely — on your own or with an AI agent. Check how a page looks, run a quick test, crawl a few public pages, save what you find, and see what you've used. The work runs on our servers, so your machine and your API keys stay out of it.

Marker: Vibecodr CLI beta guide for Quick Checks, Agent Browser, hosted Computer commands, Crawl, Saved Proof, work status, and account setup.

## Implementation focus

Reach for this when you're installing `@vibecodr/cli`, running `vibecodr start` to approve access, connecting an AI agent, checking your usage, or deciding which jobs to hand to the hosted tools.

## Expected outcomes

- See what the CLI can do, from quick page checks to longer Agent Browser tasks.
- Set up access the easy way with `vibecodr start`, or with a credential file for automation.
- See how tool credits, crawls, and build minutes are shared across your plan.
- Know where Saved Proof lives, and why only your account can open it.
- Pick the right jobs for the CLI — and know when to reach for something else.

## What the Vibecodr CLI does

Install `@vibecodr/cli` and you get the `vibecodr` command. It's the easy way for you — or an AI agent you trust — to do web work without running anything risky on your own computer. Approve access once, then ask Vibecodr's hosted tools to check a page, run a quick test, crawl a small site, save the results, and show what you've used.

Think of the command as the front door, and the tools as the rooms behind it. Quick Checks grab fast page proof. Agent Browser takes a longer look at public sites. Sandbox runs bounded tests. Crawl sweeps a few public pages. Work shows your status. And Saved Proof keeps the evidence.

- Quick Checks open a public page and hand back a screenshot, the page text, or a PDF.

- Agent Browser gives paid plans longer hosted browser sessions, with plan caps and an automatic timeout when idle.

- Sandbox runs a command or test on our servers instead of your machine.

- Crawl collects a few public pages at a time, with limits on pages, depth, and monthly totals.

- Saved Proof keeps screenshots, reports, logs, files, and long outputs so an agent can look back at them after a run.

- Work lets you follow a job's status, or cancel one that's genuinely stuck.

## How plans and limits work

The CLI's hosted tools come with every Vibecodr plan, as their own allowance. Tool credits and build minutes sit in separate buckets, so a heavy build won't eat your page-check credits, and a busy agent won't eat your build minutes.

Free gives you a small amount to try things out. Creator and Pro are built for regular use. You can always check your current limits in pricing, with `vibecodr plans`, or on the usage screen — and the live limit has the final say if a request would go over.

- Free: 30 tool credits per month, 10 per day, 1 run at a time, Quick Checks only, crawl up to 10 pages per run and 25 pages per month, no Scheduled QA.

- Creator: 600 tool credits per month, 90 per day, 2 runs at a time, Quick Checks plus 20-minute Agent Browser tasks, crawl up to 50 pages per run and 500 pages per month, Scheduled QA 30 times per month and as often as every 12 hours.

- Pro: 3,000 tool credits per month, 400 per day, 5 runs at a time, Quick Checks plus 1-hour Agent Browser tasks, crawl up to 250 pages per run and 5,000 pages per month, Scheduled QA 300 times per month and as often as every hour.

- Build limits stay separate: Free includes 30 build minutes per month, Creator includes 750, and Pro includes 4,000, with daily, job, concurrency, output size, and output file caps shown on the pricing and limits surfaces.

## Set up access safely

The simple way to set up is `vibecodr start`. It opens a browser approval page, you confirm the code while signed in to Vibecodr, and the CLI saves a durable login on your machine. After that, the `vibecodr` command knows who you are and can hand an agent the connection details it needs.

For agents or CI that can't open a browser, pass your credential from a file or standard input instead. The CLI works out what kind of credential it is, then quietly refreshes short-lived access from your saved login as it goes.

- Start with `vibecodr start` — it checks your sign-in, account, usage, service health, and agent connection in one step.

- For automation, use `vibecodr login --credential-file vibecodr-credential.txt` or `vibecodr login --credential-stdin` instead of passing a secret on the command line.

- Run `vibecodr agent status` or `vibecodr auth diagnose` when another shell or agent can't see your approval.

- Run `vibecodr agent connect --client codex` to get the connection details a compatible agent needs.

- Run `vibecodr usage`, `vibecodr work list`, and `vibecodr proof list` to see what you can run and what proof you've already saved.

Vibecodr CLI setup

```powershell
npm install -g @vibecodr/cli
vibecodr start
vibecodr connect --client codex
vibecodr computer status
vibecodr browser screenshot https://example.com --format png
```

## Set up access on a headless server

On a machine with no browser — an SSH session, a CI runner, or an agent on a headless server — skip the browser approval flow. It finishes sign-in on a local `127.0.0.1` address that a remote machine can't open, so the approval page can hang blank and the terminal never gets its success message. Reach for the device approval flow instead: `vibecodr login agent --no-browser` prints a short URL and code you approve from your phone or another computer, and the server finishes signing in on its own.

Two things keep headless setups from failing quietly. If the box has no system keychain — common on slim Linux and ARM images — set `VC_TOOLS_CREDENTIAL_STORE=file` so your login can be saved to disk instead of dropped. Then, once the machine is signed in, drive the hosted tools straight from the CLI — `vibecodr browser`, `vibecodr computer`, `vibecodr mcp call` — with no MCP client and no per-call approval. Run `vibecodr status` or `vibecodr doctor` (and their `--json`) for the full list of commands to use and the headless sign-in steps.

- Sign in without a browser: run `vibecodr login agent --no-browser`, then approve the printed code from any other device.

- In CI, skip the prompt entirely: pipe a saved credential with `vibecodr login --credential-stdin`, or point at one with `vibecodr login --credential-file vibecodr-credential.txt`.

- If a login can't be saved on a headless box, set `VC_TOOLS_CREDENTIAL_STORE=file` on a machine you trust, then sign in again.

- Run `vibecodr status` or `vibecodr doctor` for the agent recipe — the `vibecodr browser` / `computer` / `mcp call` commands to use — and to confirm the machine is signed in; both also carry the recipe in `--json`.

- Add `--non-interactive` to any command in automation so it fails fast with a clear message instead of waiting on a browser prompt.

Headless sign-in on a server

```bash
# No browser on the box? Approve from your phone instead.
export VC_TOOLS_CREDENTIAL_STORE=file   # only when there is no system keychain
vibecodr login agent --no-browser       # prints a URL + code to approve elsewhere

# Confirm sign-in and read the agent recipe (also in --json)
vibecodr doctor

# Drive the hosted tools straight from the CLI — no MCP client needed
vibecodr browser screenshot https://example.com --local
```

## Saved Proof, storage, and isolation

Saved Proof is where your run evidence lives — screenshots, PDFs, logs, reports, and command output an agent might need after a job finishes. It's kept in the hosted CLI store, separate from your editable project source and your normal project storage.

Only your account can open your proof. Every list, detail, and download checks who's asking before sending anything back, so knowing a proof ID isn't enough to grab someone else's output. Proof expires based on your retention settings — once it's expired, treat it as gone, even if the job record is still there.

- Saved Proof counts against your CLI evidence limits, not your build minutes.

- Download proof to your own workspace when you want to keep it for good.

- Don't use Saved Proof as permanent storage, app memory, or a public file host.

- Use retention settings when you want evidence to expire sooner than your plan's default.

## What agents should use it for

The CLI shines when an agent needs to act like a careful website tester: open a public page, compare it on mobile and desktop, capture console or network details, make a PDF, check the metadata, run a small diagnostic, crawl a few pages, and hand back real proof instead of a guess.

It isn't a tool for scraping the whole internet or running a browser farm. While the product is in beta, Agent Browser tasks are capped by plan, and Quick Checks stay the go-to for screenshots, page inspection, text extraction, PDFs, visual checks, and most automatic QA.

- Great fit: Quick Checks, Agent Browser inspections, runtime debugging, screenshot proof, quick accessibility scans, SEO metadata checks, visual diffs, PDFs, small crawls, and hosted test runs.

- Poor fit: bulk web scraping, open-ended automation, long-lived browser agents, or repair loops with no clear person behind them.

- Start a run only when you have a real target and know what output you expect.

- If a request is blocked by limits, sign-in, or an unsafe URL, slow down or ask the person for a safer target — don't just retry.

## Beta support expectations

The CLI tools are in beta, so commands, limits, and what's available can change as we harden them. The promise stays simple, though: access is tied to your account, the work runs on our servers, usage is tracked on its own, the diagnostics are safe to share, and your saved proof sticks around.

When something breaks, work out what kind of problem it is before retrying: setup, a plan limit, an unsafe URL, an unsupported tool, a failed job, expired proof, or a service hiccup. In a support note, include the command, the work ID, the proof ID, the status, and any public error fields — but never your API keys, tokens, private source, or links that carry credentials.

- Run `vibecodr doctor` for a quick health check of your setup and our service.

- Run `vibecodr auth diagnose` when an approval seems missing in a shell or agent.

- Run `vibecodr help <command>` for help with a specific command.

- Reach for support diagnostics when an error includes an `errorKey`, request ID, or retry hint.

## Example and read next

Example: an agent needs proof that your launch page looks right on desktop and mobile. Use the Vibecodr CLI for Quick Checks, screenshots, and Saved Proof instead of handing the agent your browser or your API keys.

Use these related pages when you need the next layer of guidance. They point to the most likely follow-up tasks, not every page that happens to touch the same system.

- Read next: /vc-tools

- Read next: /plans

- Read next: [MCP & CLI](/docs/mcp-cli)

- Read next: [MCP for Agents](/docs/mcp-agents)

- Read next: [Support Diagnostics](/docs/support-diagnostics)

- Read next: [Account & Safety Controls](/docs/account-safety-controls)

## Structured route body

### What the Vibecodr CLI does

Install `@vibecodr/cli` and you get the `vibecodr` command. It's the easy way for you — or an AI agent you trust — to do web work without running anything risky on your own computer. Approve access once, then ask Vibecodr's hosted tools to check a page, run a quick test, crawl a small site, save the results, and show what you've used.

Think of the command as the front door, and the tools as the rooms behind it. Quick Checks grab fast page proof. Agent Browser takes a longer look at public sites. Sandbox runs bounded tests. Crawl sweeps a few public pages. Work shows your status. And Saved Proof keeps the evidence.

- Quick Checks open a public page and hand back a screenshot, the page text, or a PDF.
- Agent Browser gives paid plans longer hosted browser sessions, with plan caps and an automatic timeout when idle.
- Sandbox runs a command or test on our servers instead of your machine.
- Crawl collects a few public pages at a time, with limits on pages, depth, and monthly totals.
- Saved Proof keeps screenshots, reports, logs, files, and long outputs so an agent can look back at them after a run.
- Work lets you follow a job's status, or cancel one that's genuinely stuck.

### How plans and limits work

The CLI's hosted tools come with every Vibecodr plan, as their own allowance. Tool credits and build minutes sit in separate buckets, so a heavy build won't eat your page-check credits, and a busy agent won't eat your build minutes.

Free gives you a small amount to try things out. Creator and Pro are built for regular use. You can always check your current limits in pricing, with `vibecodr plans`, or on the usage screen — and the live limit has the final say if a request would go over.

- Free: 30 tool credits per month, 10 per day, 1 run at a time, Quick Checks only, crawl up to 10 pages per run and 25 pages per month, no Scheduled QA.
- Creator: 600 tool credits per month, 90 per day, 2 runs at a time, Quick Checks plus 20-minute Agent Browser tasks, crawl up to 50 pages per run and 500 pages per month, Scheduled QA 30 times per month and as often as every 12 hours.
- Pro: 3,000 tool credits per month, 400 per day, 5 runs at a time, Quick Checks plus 1-hour Agent Browser tasks, crawl up to 250 pages per run and 5,000 pages per month, Scheduled QA 300 times per month and as often as every hour.
- Build limits stay separate: Free includes 30 build minutes per month, Creator includes 750, and Pro includes 4,000, with daily, job, concurrency, output size, and output file caps shown on the pricing and limits surfaces.

### Set up access safely

The simple way to set up is `vibecodr start`. It opens a browser approval page, you confirm the code while signed in to Vibecodr, and the CLI saves a durable login on your machine. After that, the `vibecodr` command knows who you are and can hand an agent the connection details it needs.

For agents or CI that can't open a browser, pass your credential from a file or standard input instead. The CLI works out what kind of credential it is, then quietly refreshes short-lived access from your saved login as it goes.

- Start with `vibecodr start` — it checks your sign-in, account, usage, service health, and agent connection in one step.
- For automation, use `vibecodr login --credential-file vibecodr-credential.txt` or `vibecodr login --credential-stdin` instead of passing a secret on the command line.
- Run `vibecodr agent status` or `vibecodr auth diagnose` when another shell or agent can't see your approval.
- Run `vibecodr agent connect --client codex` to get the connection details a compatible agent needs.
- Run `vibecodr usage`, `vibecodr work list`, and `vibecodr proof list` to see what you can run and what proof you've already saved.

#### Vibecodr CLI setup

```powershell
npm install -g @vibecodr/cli
vibecodr start
vibecodr connect --client codex
vibecodr computer status
vibecodr browser screenshot https://example.com --format png
```

### Set up access on a headless server

On a machine with no browser — an SSH session, a CI runner, or an agent on a headless server — skip the browser approval flow. It finishes sign-in on a local `127.0.0.1` address that a remote machine can't open, so the approval page can hang blank and the terminal never gets its success message. Reach for the device approval flow instead: `vibecodr login agent --no-browser` prints a short URL and code you approve from your phone or another computer, and the server finishes signing in on its own.

Two things keep headless setups from failing quietly. If the box has no system keychain — common on slim Linux and ARM images — set `VC_TOOLS_CREDENTIAL_STORE=file` so your login can be saved to disk instead of dropped. Then, once the machine is signed in, drive the hosted tools straight from the CLI — `vibecodr browser`, `vibecodr computer`, `vibecodr mcp call` — with no MCP client and no per-call approval. Run `vibecodr status` or `vibecodr doctor` (and their `--json`) for the full list of commands to use and the headless sign-in steps.

- Sign in without a browser: run `vibecodr login agent --no-browser`, then approve the printed code from any other device.
- In CI, skip the prompt entirely: pipe a saved credential with `vibecodr login --credential-stdin`, or point at one with `vibecodr login --credential-file vibecodr-credential.txt`.
- If a login can't be saved on a headless box, set `VC_TOOLS_CREDENTIAL_STORE=file` on a machine you trust, then sign in again.
- Run `vibecodr status` or `vibecodr doctor` for the agent recipe — the `vibecodr browser` / `computer` / `mcp call` commands to use — and to confirm the machine is signed in; both also carry the recipe in `--json`.
- Add `--non-interactive` to any command in automation so it fails fast with a clear message instead of waiting on a browser prompt.

#### Headless sign-in on a server

```bash
# No browser on the box? Approve from your phone instead.
export VC_TOOLS_CREDENTIAL_STORE=file   # only when there is no system keychain
vibecodr login agent --no-browser       # prints a URL + code to approve elsewhere

# Confirm sign-in and read the agent recipe (also in --json)
vibecodr doctor

# Drive the hosted tools straight from the CLI — no MCP client needed
vibecodr browser screenshot https://example.com --local
```

### Saved Proof, storage, and isolation

Saved Proof is where your run evidence lives — screenshots, PDFs, logs, reports, and command output an agent might need after a job finishes. It's kept in the hosted CLI store, separate from your editable project source and your normal project storage.

Only your account can open your proof. Every list, detail, and download checks who's asking before sending anything back, so knowing a proof ID isn't enough to grab someone else's output. Proof expires based on your retention settings — once it's expired, treat it as gone, even if the job record is still there.

- Saved Proof counts against your CLI evidence limits, not your build minutes.
- Download proof to your own workspace when you want to keep it for good.
- Don't use Saved Proof as permanent storage, app memory, or a public file host.
- Use retention settings when you want evidence to expire sooner than your plan's default.

### What agents should use it for

The CLI shines when an agent needs to act like a careful website tester: open a public page, compare it on mobile and desktop, capture console or network details, make a PDF, check the metadata, run a small diagnostic, crawl a few pages, and hand back real proof instead of a guess.

It isn't a tool for scraping the whole internet or running a browser farm. While the product is in beta, Agent Browser tasks are capped by plan, and Quick Checks stay the go-to for screenshots, page inspection, text extraction, PDFs, visual checks, and most automatic QA.

- Great fit: Quick Checks, Agent Browser inspections, runtime debugging, screenshot proof, quick accessibility scans, SEO metadata checks, visual diffs, PDFs, small crawls, and hosted test runs.
- Poor fit: bulk web scraping, open-ended automation, long-lived browser agents, or repair loops with no clear person behind them.
- Start a run only when you have a real target and know what output you expect.
- If a request is blocked by limits, sign-in, or an unsafe URL, slow down or ask the person for a safer target — don't just retry.

### Beta support expectations

The CLI tools are in beta, so commands, limits, and what's available can change as we harden them. The promise stays simple, though: access is tied to your account, the work runs on our servers, usage is tracked on its own, the diagnostics are safe to share, and your saved proof sticks around.

When something breaks, work out what kind of problem it is before retrying: setup, a plan limit, an unsafe URL, an unsupported tool, a failed job, expired proof, or a service hiccup. In a support note, include the command, the work ID, the proof ID, the status, and any public error fields — but never your API keys, tokens, private source, or links that carry credentials.

- Run `vibecodr doctor` for a quick health check of your setup and our service.
- Run `vibecodr auth diagnose` when an approval seems missing in a shell or agent.
- Run `vibecodr help <command>` for help with a specific command.
- Reach for support diagnostics when an error includes an `errorKey`, request ID, or retry hint.

### Example and read next

Example: an agent needs proof that your launch page looks right on desktop and mobile. Use the Vibecodr CLI for Quick Checks, screenshots, and Saved Proof instead of handing the agent your browser or your API keys.

Use these related pages when you need the next layer of guidance. They point to the most likely follow-up tasks, not every page that happens to touch the same system.

- Read next: [/vc-tools](/vc-tools)
- Read next: [/plans](/plans)
- Read next: [MCP & CLI](/docs/mcp-cli)
- Read next: [MCP for Agents](/docs/mcp-agents)
- Read next: [Support Diagnostics](/docs/support-diagnostics)
- Read next: [Account & Safety Controls](/docs/account-safety-controls)

## Related documentation

- [/vc-tools](https://vibecodr.space/vc-tools)
- [/plans](https://vibecodr.space/plans/index.md)
- [/docs/mcp-cli](https://vibecodr.space/docs/mcp-cli/index.md)
- [/docs/mcp-agents](https://vibecodr.space/docs/mcp-agents/index.md)
- [/docs/support-diagnostics](https://vibecodr.space/docs/support-diagnostics/index.md)
- [/docs/account-safety-controls](https://vibecodr.space/docs/account-safety-controls/index.md)