daemon8

Install

macOS and Linux:

curl -fsSL https://daemon8.ai/install.sh | bash

Windows PowerShell:

iwr https://daemon8.ai/install.ps1 -UseB | iex

The installer downloads the release, verifies a checksum, installs the daemon8 binary, registers daemon8 as a user-level service, and can add daemon8 MCP settings for Claude Code, Gemini CLI, and Codex.

[!IMPORTANT] Finish the instruction-file step during install. This is the one place daemon8 needs manual setup from you: let the installer add the daemon8 instruction block to your global agent instruction files (CLAUDE.md, AGENTS.md, GEMINI.md), or choose print/copy and add it yourself. That standing instruction is what makes agents connect first, use daemon8 for logs/browser/conversation state, and run the checkpointed debug loop instead of falling back to guessing.

After install, start a fresh AI CLI session. daemon8 runs locally as a machine-wide MCP server, so supported agents can talk to the same daemon across projects.

A browser extension is not required. daemon8 has its own purpose-built Chromium integration using CDP (Chrome DevTools Protocol).

First project setup

daemon8 supports Gemini CLI, not agy yet.

Start in a fresh Claude Code, Codex, or Gemini CLI session after install. The daemon8 MCP server should already be available because the installer configured the provider for you.

[!NOTE] Claude Code installs also include daemon8-channel. That channel is experimental and requires an explicit launch flag. It's an SSE path for real-time communication between harnesses; useful for experiments, but not required for normal daemon8 usage.

Then ask the agent to connect this project to daemon8:

Connect this project to daemon8 and follow any setup instructions it returns.

The agent should call daemon8_connect first. If daemon8 says the project needs setup, the agent should call daemon8_init or run:

daemon8 init

That creates a project-local .daemon8/config.md.

Open that file once and check the sources section. This is where daemon8 learns which project logs, build outputs, and runtime files matter. If the project produces log output, it should be registered there.

The important fields for a log source are:

sources:
  - id: app.logs
    service: app
    kind: file
    path: "$PRJ_ROOT/logs/app.log"
    parser: auto
    tags: ["app"]

Use parser: auto when you are not sure yet. Pick a more specific parser once you know the log format.

After that, you should see daemon8 show up naturally during non-trivial debugging: reading observations, checkpointing before changes, checking browser state, and catching up on recent conversation context when needed.

<details> <summary>Log parsers currently supported</summary>

Custom parser TOML files can also be loaded from daemon8's parser config directory, but the built-ins above are the alpha path to start with. </details>

---

Suggested alpha demos

These are the scenarios I plan to use for the first recordings:

• Break JavaScript in a frontend app and let daemon8 guide the agent through browser state, logs, checkpoints, and the fix. If Claude Code is involved, be explicit that it should use daemon8 for browser work, not Claude for Chrome.

• Return an API error and let daemon8 surface the failure through browser network activity and app/runtime observations.

• Stop a terminal session running one provider, start another provider, and ask it to catch up on the recent conversation.

• Save a message to the daemon8 feed, then ask another agent working in the same project to read the recent feed messages.

• Start a harness in your frontend and tell it to link that conversation to a backend project.

---

HTTP API

The daemon serves local endpoints for direct integrations:

SDKs are on the roadmap