🦅 BirdEye

One hub, every bird. Local-first mission control for all your AI agent harnesses — Claude Code, Claude Desktop, Codex, opencode, OpenClaw, Zcode, Gemini CLI, Cursor, Continue.

The problem

If you use more than one AI agent harness, you know this pain:

1. Every harness is an island. Each has its own sessions, memories, MCP servers, plugins, skills, and routines. Nothing is shared.

2. Memory doesn't travel. What Claude Code learned about you yesterday, Codex re-asks today. Import tools — where they exist — are per-harness and incompatible.

3. Credentials multiply. Giving agents access to GitHub means configuring auth in every single harness. N harnesses = N copies of every token.

4. Zero visibility. Which harness can touch what? How many tokens has each burned? Nobody can tell you.

5. No shared work. You can't assign a task from one place and have different harnesses pick it up.

Related MCP server: Bastion

What BirdEye does

BirdEye is a daemon on 127.0.0.1 + an interactive dashboard + one MCP gateway that every harness joins. Free, MIT, no cloud, no telemetry — your data never leaves your machine.

Quick start

Requires Node ≥ 23.6 (BirdEye runs TypeScript natively — no build step for the daemon).

git clone https://github.com/zanni098/BirdEye.git
cd BirdEye
npm install
npm run build          # builds the dashboard (one-time, ~1s)

npm run demo           # → http://127.0.0.1:4477 with rich demo data
# or scan YOUR machine:
npm run up

Then wire your harnesses into the hub:

node packages/cli/bin/birdeye.ts scan                    # inventory every harness
node packages/cli/bin/birdeye.ts register claude-code    # add the BirdEye MCP gateway (with backup)
node packages/cli/bin/birdeye.ts register codex          # ...same one-liner for each harness
node packages/cli/bin/birdeye.ts vault set GITHUB_TOKEN ghp_yourtoken
node packages/cli/bin/birdeye.ts memory sync-back        # push shared memory into every context file

The dashboard

Seven views, live over WebSocket:

• Aviary — fleet overview: one card per harness with health, counts, warnings, dispatch capability.

• Memory Graph — the shared brain, drawn: memories colored by source harness, tags, auto-extracted entities, [[links]]. Drag, zoom, filter, click any node for full detail.

• Missions — task board with live dispatch streaming.

• Sessions — cross-harness session timeline with filters.

• Arsenal — skills / plugins / MCP matrix: see instantly that github MCP is configured 4 separate times.

• Access — which harness holds which credential keys (names only), with duplication flagged — plus the encrypted vault.

• Usage — tokens and cost per harness. Honest: harnesses that don't log usage show unknown, never invented numbers.

Harness support

✅ full · ◐ best-effort · — the harness doesn't expose it on disk

The MCP gateway

birdeye register <harness> adds one entry to that harness's MCP config (original backed up first). After that, any agent in any harness can call:

Security model

• The daemon binds 127.0.0.1 only. No telemetry, no outbound calls.

• Adapters are read-only; scanning never touches your harness files.

• Credential values are never read from harness configs — key names only. The dashboard never displays secret values; vault_get flows only over local stdio MCP.

• Vault: AES-256-GCM, scrypt-derived key (BIRDEYE_VAULT_PASSPHRASE, or a machine-derived default).

• The only writers — register, sync-env, memory sync-back — are explicit commands that create timestamped backups and, for context files, only ever touch the <!-- BIRDEYE:START/END --> block.

How it runs

TypeScript monorepo, zero native dependencies, no compile step for the daemon (Node's native type-stripping). Vite builds the dashboard once.

packages/core      types · JSON store · dedup · memory graph · marker sync · vault
packages/adapters  9 harness scanners + registry (failure-isolated)
packages/server    Hono daemon: REST + WebSocket + dispatcher + demo mode
packages/mcp       the MCP gateway (stdio) + per-harness registration snippets
packages/cli       birdeye up · scan · register · vault · sync-env · memory · dispatch
apps/dashboard     React + d3-force dashboard

npm test — 62 tests across every package, fixture-driven.

Honest limits (v1)

• Usage stats depend on what each harness logs locally — rich for Claude Code/Codex, honest unknown elsewhere.

• Cursor/Continue chat data lives in app-internal storage; those adapters are shallower.

• Dispatch needs the harness CLI on your PATH.

• Cross-harness collaboration is via shared memory + shared task queue; automatic result-chaining between harnesses is on the roadmap.

Roadmap

• Result-chaining: harness A's output feeds harness B's next task

• Embedding-based memory similarity edges (currently: links, tags, entities)

• More adapters — Aider, Windsurf, Cline… (add one — it's ~100 lines)

• npx birdeye as a published npm package

Contributing

Adapters are the sweet spot — one focused file + a fixture + a test. See CONTRIBUTING.md.

MIT © BirdEye contributors