AI install

Tell your AI agent to install BlipLogger.

Your AI can handle setup, installation, verification, and your first draft. You stay in control of identity, consent, and approval.

Paste these instructions into Claude, Codex, or another capable AI assistant. Then approve the actions it asks to take.

Copy setup instructions

Paste them into your AI assistant.

Then approve the actions it asks to take.

Nothing publishes without your approval.

3-step flow

  1. 1Copy
  2. 2Paste
  3. 3Approve

What your AI can do

It can follow BlipLogger's setup flow, connect the right project, handle approved setup work, verify the result, and prepare your first governed draft.

You stay responsible for identity, consent, and approvals. Nothing goes public until you review and publish it.

Advanced details

Human approval details

Human approval can be as simple as saying "yes", "approved", or "proceed" to your AI agent after it explains the specific action it is about to take. Approval must be specific to the action being taken. Approval does not bypass BlipLogger login, billing, security, API key, or publish controls. Before making any change, the agent must describe the action and wait for the human to reply. Approval is scoped only to the action described.

Valid approval phrases

  • Yes, install it.
  • Approved.
  • Proceed.
  • Yes, add the BlipLogger widget script.
  • Create the draft.
  • - Nothing publishes without human approval.
  • - BlipLogger does not silently edit customer repositories.
  • - The customer's AI agent applies code changes in the customer workspace after human approval.
  • - Approval is scoped to the specific action described by the agent.
  • - A chat "yes" does not bypass BlipLogger authentication, billing gates, or governed publish approval requirements.
  • - Separate approval is required for: editing customer code, deploying changes, creating a BlipLogger project, creating API keys, creating draft entries, publishing, billing changes, security changes, and RBAC changes.

Canonical widget snippets

Replace PROJECT_SLUG with the project slug from your BlipLogger dashboard. Install exactly one snippet.

Default (floating panel)

<script src="https://www.bliplogger.com/widget/widget.js" data-project="PROJECT_SLUG"></script>

Side panel

<script src="https://www.bliplogger.com/widget/widget.js" data-project="PROJECT_SLUG" data-template="side-panel"></script>

Framework placement guidance

Plain HTML

Add to <head> or the end of <body> in index.html or the shared base template.

React

Add to the root component (src/App.tsx or src/App.jsx) inside the shared app shell.

Next.js

Add to app/layout.tsx (App Router) or pages/_app.tsx (Pages Router). Do not add it per page.

Vite

Add to index.html or the root component. Vite usually follows the React placement pattern.

Static site builders

Add to the root layout or site-wide template so the widget appears everywhere.

Tag managers

Inject as a custom HTML tag that fires on all pages and confirm it loads globally.

Unknown or custom app

Identify the shared shell before acting. Do not guess the install location.

Detailed install steps

  1. 1AI reads BlipLogger discovery and setup guidance, then starts the approved setup relationship when available.
  2. 2Human completes sign-in, identity, consent, or claim steps only when BlipLogger genuinely requires them.
  3. 3AI uses approved scoped authority to create or connect the project, configure the widget, and obtain install context where permitted.
  4. 4AI plans the install in the customer workspace and explains the exact change before requesting approval.
  5. 5Human approves the specific installation action.
  6. 6AI performs or records the approved install work when it has legitimate workspace access.
  7. 7AI verifies the install using the strongest supported checks and reports rollback steps.
  8. 8AI prepares the first governed draft for review where existing authority permits.

Operation levels

Public discovery

Any AI agent can discover /ai-install, /agent-install, and /llms.txt, understand what BlipLogger is, read the canonical widget snippet format, and understand the approval boundaries and what not to infer.

AI-native setup relationship

A human signs in, verifies identity, claims the setup request, or grants approval only where required. BlipLogger can then grant scoped setup authority so the AI can create or connect the project, configure the widget, plan the install, verify it, and prepare the first governed draft within the approved boundaries.

Approved workspace install

A capable AI agent with legitimate access to the customer's app, repo, site builder, or workspace can apply the approved BlipLogger setup change after human approval, then verify the result and report changed files and rollback steps.

Project-scoped AI operation

Authenticated or delegated AI surfaces can read project-scoped install manifests, setup assistant payloads, install context, verification status, and governed draft capabilities where project authorization permits. These endpoints are not public.

Machine API draft entries

A project-scoped Machine API key (write:draft scope) can create draft changelog entries only. Accepts title and body only. Publishing requires human approval in the BlipLogger governed publish flow.

Machine API - draft entries only

Authorized project-scoped API keys can create draft entries only. They cannot publish, schedule, or change settings.

  • - Machine API draft entry creation is draft-only.
  • - Requires Authorization: Bearer <key>
  • - Requires Idempotency-Key header
  • - Accepts title and body fields only
  • - Rejects publish, schedule, and status-like fields
  • - Publishing remains human-approved
  • - Payload limit: 32 KB. Title: 200 characters. Body: 20,000 characters.

Verification checklist

  • 1Use the approved setup-session or install-verification path when it is available.
  • 2Verify the widget script tag appears in the page HTML source.
  • 3Confirm data-project matches the correct authorized project context.
  • 4Open the page in a browser and confirm the BlipLogger widget UI renders.
  • 5Check the browser console for widget script errors.
  • 6Confirm only one widget script tag is present — duplicates will be rejected.
  • 7Confirm the snippet is in a shared layout or shell file, not a per-page component.

What not to infer

  • - Authenticated MCP project read tools are live: get_project_summary (scope: read:project) and list_changelog_entries (scope: read:entries).
  • - Authenticated MCP draft creation is live: create_changelog_draft requires write:draft scope, projectId, title, body, and idempotencyKey.
  • - create_changelog_draft creates draft entries only — it does not publish, schedule, or mutate display/widget state.
  • - Authenticated MCP install context tool is live: get_project_install_context requires read:project scope and returns project-specific widget snippets and MCP workflow summary. Read-only — does not mutate state.
  • - Authenticated MCP install snippet validation is live: validate_widget_install_snippet requires read:project scope. Validates submitted snippet or HTML against the authorized project slug. Read-only — does not mutate state. Does not fetch, crawl, screenshot, or access external URLs. Does not prove browser runtime rendering.
  • - Authenticated MCP widget runtime status is live: get_project_widget_runtime_status requires read:project scope. Reports BlipLogger-owned widget runtime readiness for the authorized project. Read-only — does not mutate state. Does not fetch, crawl, screenshot, browser-test, or access customer URLs. Does not prove browser rendering on the customer website.
  • - Authenticated MCP AI setup readiness is live: get_project_ai_setup_readiness requires read:project scope. Reports combined AI setup readiness: project setup status, available MCP workflows, current key capabilities, widget/runtime readiness summary, safe next steps, and hard boundaries. Read-only — does not mutate state. Does not create API keys. Does not fetch, crawl, screenshot, browser-test, or access customer URLs. Does not prove browser rendering on the customer website. Does not publish or schedule.
  • - MCP does not allow autonomous publishing, scheduling mutation, display or widget mutation, billing mutation, account or security mutation, API-key administration, approval resolution, or broad administrative mutation.
  • - MCP exposes 4 public read-only tools with no mutation authority. Its 7 authenticated tools are project-scoped and require API keys; no unauthenticated public mutation or execution authority is available.
  • - BlipLogger does not silently edit customer repositories.
  • - BlipLogger does not open PRs in customer repositories.
  • - BlipLogger does not deploy customer code.
  • - AI cannot mutate billing, security, or RBAC settings.
  • - Machine API creates draft entries only — it does not publish.
  • - Project-specific AI manifests require project authorization — they are not public.