daemon8

Look useful? Consider starring the repo.

Follow along on X:

daemon8 gives AI coding agents situational awareness while the work is happening.

AI agents are strongest when they can work from evidence: what the app is doing, what the browser reported, what another provider already tried, and what changed after a fix. daemon8 creates that layer locally. It centralizes runtime signals, recent provider activity, and debugging structure so agents can keep moving without guessing.

Open full video Browser Debugging Watch Gemini make quick work of four browser-visible errors using the purpose-built Chrome Devtools Protocol (CDP) daemon8 has access to. The agent can control JS, CSS (w/custom 3D point map layering), mobile simulation, and screenshot control. The agent can see the browser console and network errors as they happen - which land in one place. The bug fix panel shows a live SSE subscription Daemon8 provides a single convergence point, built specifically for agentic development.

Open full video Conversation Catch-up A fresh session catches up from recent provider transcripts and builds a faceted project snapshot before continuing the work. Cross-provider recovery across Claude, Codex, and Gemini context.

What daemon8 does

Put simply: daemon8 is an awareness layer for human-in-the-loop, agentic development.

It gives agents focused knowledge of what is happening right now and peripheral knowledge of what has already happened in the project (and any related project(s), e.g. frontend/backend). App logs, browser events, debug checkpoints, open investigations, and recent conversations across AI providers become one cohesive field of context the agent can query instead of guessing.

This matters because AI coding tools still live in provider-shaped rooms. Claude has one view of the work. Codex has another. Gemini has another. daemon8 starts stitching those views together with the live runtime state of the project. For this alpha, the core path is MCP-first and source-driven; provider integration utilities exist, but they are not the runtime foundation.

It gives agents one place to ask:

• What's been discussed recently in this project? (across Gemini, Codex, and Claude)
• What just happened in the app?
• What changed after this checkpoint?
• What is the browser doing right now?
• What did Claude, Codex, or Gemini already try?
• What recent project context should I know before touching this?
• Which debug sessions are still open, abandoned, or resolved?

Alpha Release

My blue-sky goals are larger than this alpha release represents. Situational awareness is the first foundation for a broader, provider-agnostic cortex for AI agents. The details and planned features will come in time.

This alpha is that foundation. Not the whole vision yet. The point is better loops today: observe, change, verify, remember.

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 can 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.

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.

Real-time subscriptions

daemon8 is not only for agents. Frontends, harnesses, dashboards, and test tools can subscribe to tagged slices of the same local observation feed while work is happening.

Observations are persisted in daemon8's local SurrealDB-backed runtime store, then streamed through GET /api/stream as Server-Sent Events. That gives a UI one path for live updates and reconnect replay while an agent works, a browser repro runs, or a chaos harness injects failures.

const params = new URLSearchParams({
  tags: "demo:chaos,project:react-chaos",
  severity_min: "info",
});

const feed = new EventSource(`/daemon8/api/stream?${params}`);

feed.onmessage = (event) => {
  const observation = JSON.parse(event.data);
  console.log(observation);
};

Tag filters are conjunctive: tags=demo:chaos,project:react-chaos only returns observations carrying both tags. The daemon endpoint is local at http://localhost:8888; browser frontends commonly route it through a same-origin dev-server proxy like /daemon8.

[!NOTE]
Native agents, CLIs, and local tools can call http://localhost:8888 directly. Browser apps are the exception: during Vite development, proxy /daemon8 through the dev server so frontend code stays same-origin.

// vite.config.ts
export default {
  server: {
    proxy: {
      "/daemon8": {
        target: "http://localhost:8888",
        changeOrigin: true,
        rewrite: (path) => path.replace(/^\/daemon8/, ""),
      },
    },
  },
};

Short-lived working set

daemon8 treats raw runtime context as a short-lived working set.

Observations, screenshots, and generated conversation snapshots are kept for roughly 24 hours. After that, they become eligible for the background cleanup sweep. The sweep runs periodically, so cleanup is not exact to the minute. In this alpha, that retention window is fixed.

Observations attached to an active debug session are protected while the session is active. If the agent forgets to close the session, daemon8 can auto-end the inactive session and write a thin summary before those observations become eligible for cleanup.

The durable layer is the thing you want to keep: resolved debug-session summaries, memory records, source configuration, and whatever you intentionally save outside the raw feed.

That split is intentional. The raw feed is the scratchpad. The summary is the memory.

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.

Core capabilities

CLI

Useful checks:

daemon8 status
daemon8 connections
daemon8 logs --follow

Common project commands:

daemon8 init
daemon8 connect --path . --provider codex
daemon8 query --severity error
daemon8 tail

Browser commands are available from the CLI too:

daemon8 browser tabs
daemon8 browser screenshot --output screenshot.png
daemon8 browser eval "document.title"

MCP tools

The MCP surface is the main interface for agents.

Responses use a common alpha envelope with status, code, message, data, requirements, hints, and next_actions. The envelope is part of the workflow; agents are expected to follow it.

HTTP API

The daemon serves local endpoints for direct integrations:

SDKs are on the roadmap

Development

From a checkout:

cargo install --path crates/daemon

For development:

cargo check --workspace
cargo test --workspace