mcp server
daedalus
A personal, self-developing AI agent you run yourself: its own app window on macOS, Linux and Windows, a web app on your phone, Telegram if you want it. Real tools (shell, browser, git, MCP), projects
Set up
Runs on your computer. Pick your agent and operating system.
Before you start
- uv (`curl -LsSf https://astral.sh/uv/install.sh | sh`)
{
"mcpServers": {
"anchor-inference-daedalus": {
"command": "uvx",
"args": [
"daedalus"
]
}
}
}same format Cursor, GitHub Copilot CLI, Junie, JetBrains AI Assistant, Augment (Auggie CLI), Factory Droid, Kiro, Devin CLI +12
Values in angle brackets are placeholders. Restart Claude Desktop after editing its config.Claude Desktop docs
README
synced Oct 21, 2026Built on protocore, an open agent core (ReAct loop, tools, context compaction, snapshots and resumable runs, memory, skills). The copy it runs on is protocore-exp.
Why
Most agent products are a chat box in someone else's cloud. Daedalus is the opposite: one operator, one installation, everything inside it — a shell, a browser, git, a filesystem, long-running services on ports you can open, a scheduler, subagents, memory — in an app window on your own machine, in a browser on your phone, and in the Telegram app you already have open if you want it there.
Where "inside it" is is your choice, and it is one download either way: a process on your machine in a folder it owns, a container from one published image, or a server you install it on.
It is built to run for weeks: sessions survive restarts, runs resume from snapshots, context is compacted instead of lost, spend is capped by a supervisor the agent cannot edit, and the agent's own improvements land as pull requests, not as silent edits.
What you get
- 💬 Telegram-native — every session has its own workspace and speaks in the chat under its own name, in the private chat or in a forum topic each; files, voice notes, inline-button questions and answers that stream as they are written.
- 🖥️ A real web app — agents, live transcripts, a file browser with previews, two sessions side by side, a ⌘K palette on a desk and four tabs on a phone; installable as a PWA.
- 🖥️ An app, not a deployment — one download opens a window of its own on macOS, Linux and Windows; native mode needs no Docker at all and is ready four seconds after launch.
- 🛠️ Real tools — shell, files, search, web fetch and search, a vision model, a Chromium you watch and take over, verification runs, MCP servers, skills loaded on demand.
- 🖱️ Your screen and your Chrome — in the native app a chat can be given one window, one app, one display or the whole desktop for a time you choose, with a border around it and Ctrl+Alt+Esc to stop; a Chrome extension (its own repository) lets the agent work in your own browser with your sign-ins, beside a side panel of its conversations. Chats, computer chats and browser chats each have a tab over the lists.
- 📁 Projects — add a folder of your own and the agents started in it work there; a path that leads out of it is refused, not followed.
- 🧭 Orchestration — a main orchestrator hands work to each project's orchestrator, which runs a team of staff (Daedalus agents or command-line agents such as Claude Code and Codex) and asks you only what it has to. From a goal to an accepted result.
- 🔁 Autonomy on a leash — loops, cron tasks, a heartbeat and boards, each run bounded by the spend and time limits you set; a provider outage pauses work instead of ending it.
- 🧬 Self-development — the agent changes its own code in a worktree and a pull request you approve in the chat, and a bad build is rolled back on its own.
- 🔐 Keys it never sees — provider keys live in a key proxy that stops paying once the daily budget is spent; ChatGPT, Claude Code and SuperGrok logins work as providers too.
- 🧾 Evidence you can open — an answer cites files and checks as chips that open at the lines it named; a change to the agent's own code needs a receipt that covers it.
- 🫧 Companion — your standing personal agent, by text and by voice: it hands work to agents, owns goals it checks on a cadence, and reports back when you are away.
Each of these at full length: docs/FEATURES.md.
How it looks
The screenshots are taken over an invented installation by tests/browser/screenshots.py; rerun it after a change to the app. The animated tours use those captures and are built by tests/browser/animated_shots.py; their scenes are listed in docs/screenshots/MEDIA.md.
The app is bilingual — Russian and English, switched in Settings (the first row) or in the More sheet on a phone, and remembered by the browser. The same pictures in Russian: docs/screenshots/ru/.
How it is put together
Diagram sources: docs/diagrams/ is rendered from the mermaid text kept beside the README.
The diagram is the full stack with every profile on. A default install is two of those containers, from one image: the agent, and the key proxy that holds the provider keys. SearXNG, the rebuilder and the local Bot API server are the three profiles, off unless you ask for them. The agent container has no provider keys and no docker socket; the supervisor and the governance rules are mounted read-only. Services the agent hosts (a demo site, a dev server) listen on a published port range and can be shared through your domain — to anyone, or to whoever holds a key — without opening another port. A dialog is shared the same way, from its menu: only in the app, by a private link, or by anyone who has the link. The page shows the messages and the pictures in them, and it keeps updating until sharing is turned off. Tool calls, files and thinking stay in the app.
In native mode the boxes are the same and the containers are not there. The supervisor and the key proxy are two processes the launcher starts, the key proxy on 127.0.0.1 instead of a private network, and the workspaces and the state are files in the installation's own folder instead of volumes. The supervisor is the same program either way: it has never known what a container is.
A run, step by step
Where a run happens: a session works either in a project — a folder you added, which is both its working directory and the limit of its reach; every path it resolves is checked against that root, so a .., an absolute path elsewhere and a symlink out of the tree are one refusal — or, with no project, in a scratch directory of its own under the workspaces root, which is how every session worked before projects existed and still works today. Snapshots are on for a scratch workspace and off for a project until you turn them on: a project root is your repository, and committing it twice a turn costs more than the undo repays.
What makes long sessions work: the transcript retains messages through compaction, while the working history the model sees is shortened into summaries (with HistoryExpand to read the originals back). Regenerate permanently deletes the selected assistant message and everything after it, then answers again in the same session. Revert permanently deletes the selected user message and its tail, and restores files only if an existing checkpoint is available. Neither action creates a backup or a branch. Fork explicitly creates a separate session from an earlier point; /clear starts a fresh working history while retaining the transcript and files.
What makes them survive: runs resume from snapshots after a restart; a run the provider dropped is retried in place by the core and, when the provider stays down, driven again by the host after a wait that doubles per failure (ops.provider_retry_*, 30 s to 10 min, six attempts); a context overflow is compacted and the turn driven again; the core's own wind-down notice never outlives the run it was written for.
Self-development
The PR text passes a public-text gate (nothing about your machine leaks into a public repository), the diff is checked for references it must not carry, and GOVERNANCE.md — the rules the agent always sees and can never edit — is mounted read-only. Approval is manual by default; /approval auto hands it over when you trust it.
Not every installation does this. [self_change] mode is off, local or server, and auto — the default — works out which one this installation can honour when it starts:
| mode | what it means | what it needs |
|---|---|---|
server | worktree → pull request → your approval → merge → rebuild, as above | a GitHub token, an origin on both checkouts, and a way to deliver a build (the supervisor socket or the compose rebuilder) |
local | the agent edits the checkout this installation runs from; there is no fork and no PR, and the change applies after a restart | a writable git checkout of the host and the core |
off | the agent does not change its own code | — |
How local mode checks a change before it restarts on it, the gates both modes share, and what else follows the mode: docs/SELF-DEVELOPMENT.md.
The toolbox
| Area | Tools |
|---|---|
| Files & shell | Exec (inside a bubblewrap sandbox — the default on a native install where a namespace probe succeeds, optional in a container, which is a boundary already; background=true with JobOutput / JobKill / JobList for what outlives the call, and JobWait for a pid, a file, a log line or a port; every job that ends — or is lost to a restart — wakes the session once with its outcome; a long sleep, a polling loop in the foreground, or a pgrep -f that would find its own shell is refused), Read, Write, Edit, Find, Search |
| Web | WebFetch, WebSearch — DuckDuckGo out of the box with no key at all; a self-hosted SearXNG, installed from Settings → Components (natively too, without Docker) or run as a profile; Serper, Tavily, Exa, Perplexity, Keenable through the key proxy |
| Seeing | ImageView — a separate vision model answers questions about an image, so the main context never carries pixels |
| Browser | BrowserOpen, BrowserSnapshot, BrowserAct, BrowserText, BrowserLook, … — a real Chromium you can watch live and take over, driven by an outline of the page with refs; logins kept per project; page content fenced as data; passwords and payments left to you (BrowserHandoff); a purchase, a message sent, a deletion or an upload asked about first. Command-line staff get the same tools through their launch's MCP entry. Only on an installation with a browser daemon (docs/architecture/browser.md) |
| Delegation | SubAgent, SubAgentSend, SubAgentList, SpawnAgent, AskPeer — helpers in the same workspace (a report wakes the leader when it is ready; an idle helper can be raised without a task; tools_off takes tools away from a helper, so a launch it must not make is impossible rather than discouraged), sibling sessions, named peers |
| Time | ScheduleCreate, LoopNext, IntentCreate — cron, self-paced loops, standing intents on inbound events |
| Hosting | ServiceStart / ServiceStop / ServiceLogs — processes that outlive the turn, on ports you can reach and share; TerminalRead — the screen, output and commands of the session's own terminals, read-only |
| Pages | PageCreate, PageWrite, PageImport, PageCheck, PagePublish, PageShow, … — screens of your own inside the app, at /app/p/<slug> and on the rail: built from a template or with any toolchain and imported, looked at on a phone and a desktop in both schemes before you see them, published and rolled back without a restart; a page may have an agent of its own beside it (PageBind, PageEmit, PageStorage) (docs/PAGES.md) |
| Widgets | Widget — an interactive element inside the answer (a calculator, sliders, a small chart, a checklist): one HTML document drawn in a sandboxed frame with no network, following the theme, keeping what you enter, and one click from becoming a page (docs/PAGES.md) |
| Memory | Remember, Recall, Forget, HistorySearch, HistoryExpand |
| Quality | Verify — a check with a criterion, recorded as a receipt; LearningReport |
| Self | SelfWorkspace plus either SelfApply (local: commit into the running checkout, restart to apply) or SelfPropose, SelfRebuild, SelfRollback (server: pull request, rebuild, roll back) — registered according to [self_change] mode; on an installation that does not change its own code there are none |
| Planning | BoardAdd / BoardUpdate / BoardList / BoardGet — the agent's own board (shared with its subagents; tasks you post to nobody in particular are on every board), with acceptance criteria, checklists, dependencies and a per-agent work-in-progress limit; PLAN.md in the workspace is its rendering |
| Extensions | Skill (37 bundled skills: design systems, web QA, writing, scheduling, comparable variants, figures, search discipline…), Mcp* with OAuth, SendFile (attached under the answer in the app too), StaySilent, Notify — tells you something outside the chat, routed like any notification and limited per session |
Every tool can be switched off per session from the app. There are no answer modes: the agent works until the job is done, bounded only by the spend caps you set, and the two switches beside the model are YAGNI (the smallest change that does the job) and Autopilot.
What the agent may do
Every tool call is judged from its arguments before it runs — a shell command is parsed into its
simple commands first, so cd x && rm -rf / is seen as rm -rf / — and the answer is allow, ask
or deny. A denial is final. An ask is a denial you can lift: the refusal carries a key, and
Allow once in the app or /allow <key> in the chat lets that one exact call through, once.
The built-in rules are in the repository (daedalus/host/policy.py), so they change only through a
reviewed change; your own rules in config.toml can add denials and questions and can never lift a
built-in one. A project contains every path a session resolves, the spend caps belong to a
supervisor the agent cannot edit, and daedalus doctor prints what this installation's boundary
actually is in one line. The native-only rules, what a project does and does not contain, and the
egress allowlist: docs/POLICY.md.
Run it
Two programs, three ways in. The desktop app is the one to start with; the server install is the same stack with a domain in front of it. Everything below is in full in docs/INSTALL.md.
The desktop app — one download, one folder, nothing installed system-wide:
curl -fsSL https://raw.githubusercontent.com/anchor-inference/daedalus/main/desktop/install.sh | sh
That takes the newest desktop-v* release, checks its signature and its SHA256SUMS and unpacks it
into ./Daedalus; the archives are also on the releases
page. Releases are signed with the project's release key, minisign key id A18524FA935353DF:
RWTfU1OT+iSFoaxGzNfGzkwHdVs2o8WmnCzBUo/LBUw2L4ssGN4xYx/2
The installer prints that key's fingerprint before it installs anything — it must read
f75fa5a293fdd55b36c794f4787f7af8646e4dac95e19d74e6288e55c357c285, the SHA-256 of the line above —
and desktop/SIGNING.md shows how to check a release by hand. Open it, choose native (no Docker, about 100 MB, 4 s warm) or Docker, give it a provider
key and a daily cap, and it hands you the app. desktop/README.md has the rest.
| Native — no Docker | Docker | |
|---|---|---|
| Needs | nothing at all | Docker Desktop or Docker Engine |
| First run fetches | 103 MB on Linux, ~96 MB on macOS, ~148 MB on Windows — a pinned uv, a CPython, rg and the app's environment, each checked against the hash its publisher published | 114 MB to pull one image (478 MB unpacked), plus Docker itself: a ~600 MB application with a VM disk behind it |
| Ready in | 26 s from an empty folder, 4.3 s warm | seconds, once Docker is up |
| The agent is | a process under the launcher, which keeps it alive and stops it on quit | a container that comes back with the machine |
| Isolation | the policy rules, and bubblewrap on Linux where it can actually run — see what each gives up | the container's own edge |
A server — Docker with Compose, and one model API key or a ChatGPT / Claude Code / SuperGrok login on the host. Telegram is optional: without a bot token the app in the browser is the whole interface.
git clone https://github.com/anchor-inference/daedalus
cd daedalus
bash deploy/setup.sh # asks for the values, writes .env and ../daedalus-secrets/keyproxy.env, starts the stack
Every other piece is a profile, off unless you ask for it:
--profile | What it starts | Cost |
|---|---|---|
telegram | the local Bot API server: files up to 2 GB instead of 20 MB (it needs TELEGRAM_API_ID / TELEGRAM_API_HASH from https://my.telegram.org/apps) | ~66 MB |
search | a self-hosted SearXNG. Without it WebSearch goes to DuckDuckGo directly; with it, SearXNG is the backend the tool falls back to. Settings → Components can instead install SearXNG into the state volume, which the supervisor runs beside the agent | ~382 MB |
selfdev | the rebuilder, the only container that can reach Docker. Needed only to build a new agent image, which is what a change to the image's own recipe asks for | ~237 MB |
browser | the agent's browser: browserd and Chromium from the :browser image target, on a network of its own (more) | the :browser tag |
Or have a coding agent do it. docs/AGENT-SETUP.md is written for one — every step a command with the output it must see. Paste this into the agent, on a shell with Docker on the target server:
Install Daedalus (https://github.com/anchor-inference/daedalus) on this server for me, following the
instructions for agents in docs/AGENT-SETUP.md of that repository exactly. Before you start, ask me
in one message for everything section 1 of that page needs (a model key or a CLI login to use,
whether I want Telegram, whether there is a domain, the daily cap, a GitHub token or "later").
Then clone, configure, start the stack, verify it as the page says, and give me the pairing link
and the two-line summary section 8 asks for. Never paste keys or tokens back into this chat.
Whichever way you install it, the app opens on Add a model until one exists: the installation ships
with no model picked for you. With no Telegram bot, every start writes a one-time pairing link to
pairing-url in the state directory; a fresh one:
docker compose -f deploy/compose.yaml exec daedalus python -m daedalus auth pair
Then, if you like, switch on two-factor sign-in in Settings → Security: after the link or Telegram, the login screen also asks for the six digits from an authenticator app.
More in docs/INSTALL.md: terminals, the agent's browser, the host terminal, what each way of running gives up, signing in without Telegram, with Telegram, models and keys, without Docker, for development.
Commands
| Command | Effect |
|---|---|
/new <title> | new session (a new topic when a group is bound) and write to it |
/use <n|title> | in the private chat: write to that session from now on |
/stop, /close | stop the current run; put this session away (closing its topic when it has one) |
/rename <title> | rename the session and its topic |
/compact [focus], /clear | replace the history with a summary; start over with an empty history (files, brief and settings stay) |
/model [preset], /thinking … | model and thinking for this session |
/yagni [on|off] | ask for the smallest change that does the job; the next turn is told, the system prompt stays as it is |
/loop [10m] <instruction> | make this session a loop agent; status, pause, resume, stop, remove |
/brief [text], /cap <usd> | standing instructions; spend cap for the session |
/sessions, /status, /usage, /balance | the numbered roster; what is running; spend; provider balances |
/schedules, /schedule run|on|off|delete <id> | scheduled tasks |
/board, /inbox, /intents, /peer | every agent's board tasks, the inbox, standing intents, peers |
/allow <key> | grant once a call the policy asked about |
/approval manual|auto, /verbosity 0|1|2 | self-change approval; how much of a run the chat shows |
/heartbeat, /doctor [fix], /settings, /prompt | the periodic check; health checks; configuration; the working rules |
/rebuild, /rollback [n], /panic | supervisor operations |
Every session command also works from the app's composer with the same / palette.
Documentation
| docs/FEATURES.md | what you get, each feature at full length |
| docs/INSTALL.md | the desktop app, a server, terminals, the agent's browser, the host terminal, signing in, Telegram, models and keys |
| docs/AGENT-SETUP.md | a server install written for a coding agent to follow |
| desktop/README.md | the desktop launcher: its folder, window, modes, releases |
| docs/CONFIGURATION.md | .env, config.toml, MCP servers and the guard rails |
| docs/POLICY.md | what the agent may do, and where the boundary is |
| docs/SELF-DEVELOPMENT.md | the three self-development modes in full |
| docs/ORCHESTRATION.md | a project from its goal to an accepted result: autonomy, review, the team, host folders |
| docs/API.md | the HTTP API: files, steers, the event stream, notifications, projects, orchestration, push |
| docs/COMPANION.md | the companion: goals, its tools, the two models, hearing you, speaking back |
| docs/PAGES.md | custom pages: your own screens inside the app, the kit, the bridge, the API |
| docs/DEVELOPMENT.md | the repository's layout, and benchmark runs |
| docs/architecture/ | the browser, the terminals, conversation search |
License
MIT.