> ## Documentation Index
> Fetch the complete documentation index at: https://docs.befailproof.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Quickstart

> Capture an agent session, find a failure, and start preventing it.

This quickstart gets one machine reporting sessions, runs an audit, and deploys a policy. Use the skill to set Failproof up, or follow the manual steps.

**Which path is yours?** If your agent runs in one of the 12 supported [harnesses](/reference/harnesses) — a coding CLI, or a gateway like Hermes or OpenClaw — follow the steps below; you need Node.js 20.9 or later. If your agent has no harness, instrument it with the [Python SDK](/reference/custom-agents) for tracing and audits, then rejoin at [Run your first failure check](/start/first-audit); enforcement on that path needs a hook in your runtime.

<Tabs>
  <Tab title="Use the skill">
    <Steps>
      <Step title="Install the Failproof AI skills">
        ```bash theme={null}
        npx skills add FailproofAI/skills
        ```
      </Step>

      <Step title="Ask your agent to set everything up">
        ```text theme={null}
        Set up Failproof AI for this project, connect this machine, install the right hooks and policies, and verify that a session arrives.
        ```

        Your agent inspects the project, chooses the relevant integration, performs the setup, and verifies it. See the [FailproofAI skills repository](https://github.com/FailproofAI/skills) for individual skills and advanced installation options.
      </Step>
    </Steps>
  </Tab>

  <Tab title="Manual setup">
    ## Before you start

    1. Open the [Failproof AI dashboard](https://app.befailproof.ai) and create an account or sign in with your work email.
    2. Go to **Administration → Keys** and create a key with `events:add` and `policies:pull`. If you plan to use [Jev through FailproofAI Cloud](/reference/jev-cloud), choose the **machine** preset, which also grants `jev:evaluate`.
    3. Copy the one-time secret, then read it into a shell on the target machine. `read -s` takes it at a prompt that does not echo, so it never appears in a command:

    ```bash theme={null}
    read -rs FAILPROOFAI_KEY && export FAILPROOFAI_KEY
    ```

    ## Install

    <Steps>
      <Step title="Install and connect Failproof AI">
        ```bash theme={null}
        npm install -g failproofai
        FAILPROOFAI_CLOUD_TOKEN="$FAILPROOFAI_KEY" failproofai config
        ```

        That one command is the whole of setup: it installs the local daemon (root once), wires hooks into every agent CLI it finds, and connects this machine to Cloud. Passing the key through the environment rather than `--token` keeps it out of `ps`, where every user on the machine can read a command's arguments. It does not keep it out of shell history — reading it with `read -s` is what does that. In CI, inject it as a masked secret and keep shell tracing (`set -x`) off, or the trace prints it.

        Session transcripts are sent by default. Add `--no-transcripts` to report hook activity and policy decisions without transcript content.

        <Warning>
          Do not reach for `failproofai config --connect <url>` here. That flag enrols a machine that is **already** set up and returns straight after — no daemon, no hooks — so the machine would appear in Cloud while collecting and enforcing nothing.
        </Warning>

        If this machine already has agent history, preview and import the last seven days, then wait for delivery to finish. Skip this step on a new machine.

        ```bash theme={null}
        failproofai backfill --since 7d --dry-run
        failproofai backfill --since 7d
        failproofai flush --wait
        ```

        Open **Sessions** in Failproof AI and select an imported session.
      </Step>

      <Step title="Attach Failproof AI to a harness">
        The previous step already wired every agent CLI it detected. Re-run it for one harness explicitly when you need to, or to add a harness installed afterwards. Every one of the 12 is a valid `--cli` value — `claude`, `codex`, `copilot`, `cursor`, `opencode`, `pi`, `hermes`, `openclaw`, `factory`, `devin`, `antigravity`, `goose`.

        ```bash theme={null}
        failproofai policies --install --cli claude --scope user     # a coding CLI
        failproofai policies --install --cli hermes --scope user     # a Slack/Telegram gateway
        ```

        Blocking a tool call before it runs is verified on all 12. Turn-end gates are verified on 8 — see [enforcement capability](/reference/harnesses#enforcement-capability) for the per-harness matrix.
      </Step>

      <Step title="Choose what to enforce">
        Wiring hooks enables no policy. Setup deliberately picks none — that decision is yours — so take a pack:

        ```bash theme={null}
        failproofai policies add FailproofAI/policies
        ```

        The pack is fetched from its GitHub release, checksum-verified, and pinned to the exact tag it resolved. It carries 39 policies and switches on the 10 its manifest marks as safe to enable unattended. Use them to see local policy decisions and try enforcement before Failproof AI audits your sessions and writes policies for your agents.

        Read any pack before taking it with `failproofai policies show <owner>/<repo>`, and see [policy packs](/policies/packs) for taking only part of one.

        Until this runs, the only thing enforcing is `block-failproofai-commands` — the always-on guard that stops an agent switching Failproof AI off. `failproofai policies` lists what is on.
      </Step>

      <Step title="Audit the behavior">
        Follow [Run your first failure check](/start/first-audit). Use a concrete goal such as “find sessions where the agent retried a failing tool without changing its approach.”
      </Step>

      <Step title="Prevent the failure">
        Follow [Prevent your first failure with a policy](/start/first-policy). Start in observe mode, inspect matches, then enforce the reviewed version.
      </Step>
    </Steps>

    <Check>
      Run `failproofai config --status`. A healthy setup reports the cloud connection, daemon state, and whether enforcement is paused.
    </Check>
  </Tab>
</Tabs>

## Jev setup

Use [Jev](/start/use-jev) to score finished sessions against a question with known answers, or to review tool calls in context before they run. The **Use Jev** page has both setup paths.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.