Up and running in five minutes

01Download & launch

Grab the ~4 MB mdo.exe from the download page, put it in any writable folder and double-click. The first launch creates mdo-home/ beside the exe and opens the native window — that is the entire installation: no registry, no AppData, zero C-drive footprint.

# run directly after downloading — no installer
.\mdo.exe

# headless read-only smoke check: creates and modifies nothing
.\mdo.exe -- --help

On Android, install the ~3.8 MB APK and launch once — the private in-app Home is created for you.

02First task

Create a task in the default project and start talking. New tasks in the default project use mdo-home/workspace/ as their dedicated working directory, created on first use — never the program or launch directory. Existing sessions keep the working directory recorded at creation; explicitly specified paths always win.

The timeline streams replies, tool calls, artifacts and reasoning live — events arrive over a same-port WebSocket, no polling; every side effect raises an approval request first. Reopening an old task loads history page by page in rounds, and context compaction never deletes what you see. The top bar switches the UI between 中文, English and Русский.

03Configure models

The built-in free default model ornith-1.5-35b (Responses by default, with Chat Completions and Anthropic interfaces, a 240K context window) works out of the box — no key required.

To plug in your own models, open Settings → Models: first create a provider (endpoint, TLS validation, timeout), then a model profile (wire model name, protocol set, context and output windows). Providers and models are separate, so one model can hang off different connections.

{
  "providers": [{
    "id": "my-provider",
    "endpoints": { "responses": "https://api.example.com/v1" },
    "credential": { "secret_ref": "env:MY_PROVIDER_KEY" }
  }],
  "items": [{
    "id": "my-model", "provider": "my-provider",
    "wire_model": "example-large", "protocols": ["responses"]
  }]
}

Plain JSON config never stores api_key, token, password or similar secrets in clear text: credentials only exist as secret_ref references (env:, file:, keychain: or prompt:), resolved at use time and released right after. The authoritative field definitions live in the repository's configuration contract.

04Permissions & approvals

mdo's default posture is "guideline first": file writes need write-admission tokens, web tools obey domain and address policies, and every side-effecting agent call raises a per-call approval — you can tune the strictness in Settings.

• Interruption recovery: after a cancelled or interrupted run, the recovery view lists every unsettled pending call; each needs your explicit RETRY (re-runs and re-checks permissions) or RECORD_UNCERTAIN (skips the call and writes a traceable uncertain result). Only tools known to be read-only may auto-retry.
• Web trio: web_search and web_open actually go online with public-address enforcement; web_find only reads an in-process document snapshot. Search access comes from account login (PKCE) with device-encrypted credentials.
• Audit: approval decisions, tool results and recovery history are all journaled and replayable.

05Portable multi-Home

Runtime data goes only into the mdo-home/ beside the executable — no registry, no AppData, nothing uploaded. Worried about filling your system drive? Put the exe on any disk, or point --home / MDO_HOME at another drive, an external disk or a USB stick (the former wins). Both only compute the path; uninstalling means deleting one folder, zero leftovers.

# USB stick portable mode: exe + Home travel together
E:\mdo.exe -- --home E:\mdo-home

# zero C-drive footprint: live on D:
$env:MDO_HOME = "D:\mdo-home"; .\mdo.exe

Legacy data/ beside old executables and .mdo/ in your user directory import via Settings → Migration: explicit preview, confirmation token and atomic publication; the target Home must not exist and the old directories are never modified. See the legacy migration notes.

06Advanced

• Memory: global and per-project MEMORY.md files. The agent uses plain file tools; you edit the same file in Settings. Snapshot fingerprints make stale UI saves fail explicitly after direct file edits — no silent overwrites.
• Skills: external Skill directories are full trust boundaries — an external directory with the same ID shadows the built-in Skill entirely; scripts and resources are API-readable only when declared in front matter.
• MCP: stdio and HTTPS Streamable HTTP transports; secrets exist only briefly inside candidate registration and are never returned by catalog or status APIs.
• C modules: drop C sources into agents/, subagents/ or tools/; they compile through restricted TCC with transactional hot reload over the public ABI in include/mdo/module.h.
• Scheduled tasks: tasks created in Settings reuse the full permission and audit chain of normal agent runs and resume after restart.

07Device Link

After signing in to the same member account, phone and PC can select and control each other from the sidebar device entry. Remote control is off by default: only after you explicitly enable it in Settings does the device connect outbound to the official relay (TLS transport, no open ports).

• Select to take over: once a target is selected, chat, projects, files, approvals, settings and updates all act on the target device; the header always shows the target identity and the read-only/control mode.
• Watch read-only first: start in read-only mode to observe the target's state, then switch to control when ready.
• Receipted writes: write requests carry a unique ID and content fingerprint; the target deduplicates and receipts them. Writes freeze on disconnect — never falling back to the controller's local data.
• Same-account isolation: the server validates member sessions and device ownership; cross-account devices cannot be queried or connected.
• Restrained on mobile: Android requests background resources only while remote control is on, releasing them on close, revoke or sign-out; system and vendor policies apply — no promise of unlimited background uptime.
• Nothing stored at the relay: forwarded content passes through memory only — no database, no access logs.

The full protocol and acceptance records live in the repository's device remote-control contract; for the overall data pledges see data security commitments.

For deeper contracts (session storage, backup/restore, web-tool boundaries, module ABI…), read the MIT repository's docs/ directory directly — every document evolves alongside the code.