# What Daktyl Connect is Your coding agents, on your machines, from your phone. Source: https://daktylconnect.com/docs/ Daktyl Connect puts the coding agents already running on your computers on your phone. Chat with them, take the call hands-free, approve a risky command from the lock screen, open a port on a machine and tap it, and steer the whole fleet. Free in V1 · invite-only preview ## The shape of it One always-on hub that every machine dials out to; a daemon on each computer as the hands; the channel plugin as each agent's voice; the phone app as the cockpit. Nothing is peer-to-peer and nothing listens for inbound connections, so a NAT'd desktop, a cloud box and a laptop on hotel wifi all behave the same — no port forwarding, no VPN, no inbound anything. - Your machines, your data. Agents run on hardware you own. The hub coordinates them; it does not host, copy or back up your work. There is no cloud backup, by design. - Accounts are isolated from each other, and all traffic is encrypted in transit. - Harness-neutral. Claude Code, Codex, Copilot, opencode, Hermes, Antigravity and more are equals — see Harnesses. ## What you can do Thing | Where Chat with a live agent | phone, desktop cockpit, daktyl chat Voice calls | phone — Voice calls Send a photo to an agent | phone — Photos Approve a tool call | lock-screen notification Start / stop / retask agents | phone, daktyl create, daktyl kill Open a port and view it | agent opens it, you tap it — Tunnels Run on your own model | Local models ## Supported hosts Linux and macOS. Windows runs Daktyl Connect under WSL today (wsl --install in PowerShell, then the same commands in the WSL terminal); native Windows comes later. The cockpit app is iOS. ## Start here curl -fsSL https://app.daktylconnect.com/install.sh | sh daktyl connect Install and connect → ## For models These pages are also published as text: llms.txt (the index) and llms-full.txt (every page, in this order). ---- # Install and connect One command installs it; one more puts the machine on your phone. Source: https://daktylconnect.com/docs/install.html ## Install curl -fsSL https://app.daktylconnect.com/install.sh | sh This installs the daktyl CLI and the channel plugin under ~/.daktyl/. Nothing needs root and nothing is added to a system path you do not own. ## Connect the machine daktyl connect connect is the one verb: it signs you in, registers this computer, and starts its daemon — skipping whatever is already done. If you are not signed in it prints a QR code to scan with the app, which pairs the machine to your account. Run it again any time; it is idempotent. Headless box with no browser? daktyl account login --manual prints a URL you can open anywhere and paste the token back. ## Check it daktyl status # hub health, who you are signed in as, registered machines daktyl doctor # read-only health check of this machine daktyl fleet # every agent and seat across the fleet ## Register a project A project is a directory an agent may be launched into. Register the one you are standing in: daktyl project add # registers $PWD daktyl project ls ## Start an agent daktyl create # guided: name, harness, model, permissions, project daktyl create --harness codex --project my-repo # every question a flag answers is not asked A fully flagged invocation is scriptable and needs no terminal. From then on the agent is on your phone: chat, calls, status, approvals. ## Keep it current daktyl update # self-update the CLI + plugin from the hub (sha256-verified) daktyl update --check # report what is available, change nothing ## Windows Daktyl Connect runs under WSL. In PowerShell: wsl --install, restart, open your WSL terminal, then run the two commands above. Native Windows support comes later. ## Remove it daktyl uninstall ---- # The CLI Every verb, captured from the installed `daktyl --help`. Source: https://daktylconnect.com/docs/cli.html Captured verbatim from daktyl --help on the installed CLI when this page was generated — it is the CLI itself talking, not a transcription. Version captured: daktyl 0.6.12 (c142df5.2026-09-21). The blocks below reproduce terminal output at its native width; on a narrow screen they scroll sideways. ## daktyl --help usage: daktyl [args] daktyl — the Daktyl Connect CLI. things you can manage: daktyl account who this machine is signed in as daktyl account status hub health, identity and who you are signed in as daktyl account login Google sign-in in a browser -> app token in ~/.daktyl/ daktyl account logout forget the saved token daktyl agent the agents on this machine daktyl agent ls list the agents on this machine (panes and harness seats) daktyl agent create create an agent, guided — name, harness, model, permissions, project (flags answer any question up front) daktyl agent attach attach to an agent's terminal (harnesses that have one) daktyl agent kill stop one agent (local first, hub fallback) daktyl agent role read or set an agent's role (leader, owner:app, worker) — what `role:` targets resolve to; `none` clears daktyl project the projects this machine hosts daktyl project ls the projects this machine hosts, and who is running in each daktyl project add register a project: `add [path] [id]` — no path registers $PWD daktyl project rm unregister by id (prompts if agents are running there) daktyl sessions the hub's session rows daktyl sessions prune delete named dormant rows: `prune ` (explicit names; the hub re-checks each) daktyl keys pinned owner signing keys daktyl keys list the owner signing keys pinned on this machine daktyl keys add pin an owner pubkey: `add [label]` daktyl keys remove unpin by kid or pubkey daktyl keys pair QR-scan trust bootstrap with the phone daktyl keys fingerprint show the kid/fingerprint for a pubkey daktyl machine this computer and the fleet it belongs to daktyl machine ls list registered computers (and the build each reports) daktyl machine update roll the published CLI onto hosts through the hub: `update --all | …` (`--wait ` reads back what each reports) daktyl machine doctor read-only health check of this machine daktyl machine retention what auto-deletion WOULD do: `retention [status|keep|unkeep ]` daktyl machine uninstall remove the CLI (see `uninstall` below) things you can do: daktyl attach attach to an agent — its tmux session if it's local (Ctrl-b d to detach), else the chat REPL (harness seats, other hosts) daktyl chat open a live terminal chat with a running agent (like the app's Live tab) daktyl create create an agent, guided — name, harness, model, permissions, project; any question answered by a flag is not asked, so a fully-flagged invocation is scriptable and needs no terminal daktyl kill stop one agent — local tmux first, hub fallback daktyl connect [name] sign in + register this computer + start its daemon (skips what's done) daktyl init [name] register this computer and set it up: channel plugin, login supervisor, default project, daemon — not signed in? shows a QR to scan with the app daktyl status hub health, identity, registered machines daktyl fleet every agent and seat across the fleet — state, model, context, freshness daktyl usage an agent's token/context history (what the app's chart draws) daktyl probe [message] send one message AS YOU and wait for the reply (+ the turn's telemetry) daktyl daemon [start|stop|status] this host's daemon — heartbeats to the hub + executes fleet actions daktyl daemon start start it in the background (bare `daktyl daemon` does the same) daktyl daemon stop stop the background daemon daktyl daemon status running? where's the log? does it survive logout? daktyl runner [install|status|remove] the release runner this machine keeps in its login session — a tag on a repo becomes a build here daktyl runner install download GitHub's runner (checksum-verified), register it for one repository, write + start the login service daktyl runner status each runner: registered? listening? which repository, which labels daktyl runner remove stop, deregister (with a removal token) or drop locally, delete the directory daktyl update self-update the CLI + channel plugin from the hub (sha256-verified) daktyl uninstall remove the CLI daktyl doctor read-only health check of this machine daktyl logs the daemon's log: `logs [-n 200] [--since 15m] [--level warn] [-f] [--json]` (reads across rotation; pipe it anywhere) daktyl completion bash|zsh print a shell-completion script: eval "$(daktyl completion bash)" options: --manual headless login: open the printed URL anywhere, paste the token back (account) --host H create on another registered machine (skips attach) (agent) --harness H which harness to run (default claude-code) (agent) --model M pin the model at launch (agent) --effort L pin the effort level at launch (agent) --project P launch inside a registered project (agent) --role R pin its role at creation (leader, owner:app, worker) (agent) --bypass / --no-bypass launch with or without --dangerously-skip-permissions (agent) --ephemeral keep no history after it stops: identity, artifacts and hub rows dropped on kill (agent) --yes rm: skip the confirmation (project) --keep-agents rm: unregister but leave running agents alone (project) --host H create it on another registered machine (create) --harness H which harness to run (default claude-code) (create) --model M pin the model at launch (create) --project P run it inside a registered project (create) --bypass / --no-bypass run tools without asking / ask first (create) --all stop every agent on this host (confirms; --yes skips) (kill) --yes skip the confirmation (kill) --dev developer machine: the plugin from that checkout's mcp/claude-channels, and it becomes the default project (init) --project the default project agents start in (init) --no-setup register only (plus the daemon phase); skip plugin, supervisor and project (init) --rekey re-register even though this computer already is (rotates the host key; the daemon reconnects) (init) --foreground run in this terminal (what systemd and tmux use) (daemon) --allow-sibling start beside a live daemon anyway (they BOTH execute every command) (daemon) --url U the repository (https://github.com//) — one runner per repository, by design (runner) --token-stdin / --token-file P the registration or removal token (never on the command line) (runner) --labels a,b runner labels (default mac-build — what every lane's runs-on asks for) (runner) --no-start write the service, do not bootstrap it (runner) --check report what's available, change nothing (update) --force reinstall even when the commit matches (update) --all also stop the daemon + agents, deregister, remove plugin + config (uninstall) --yes skip the confirmation (uninstall) -h, --help show this help; add --markdown for the full reference -V, --version print the CLI version and exit --server SERVER hub base URL every command prints what it can do when you leave the rest out. config: ~/.daktyl/config.json ## Per-verb help ### daktyl account usage: daktyl account who this machine is signed in as daktyl account status hub health, identity and who you are signed in as daktyl account login Google sign-in in a browser -> app token in ~/.daktyl/ daktyl account logout forget the saved token options: --manual headless login: open the printed URL anywhere, paste the token back everything: daktyl --help ### daktyl agent usage: daktyl agent the agents on this machine daktyl agent ls list the agents on this machine (panes and harness seats) daktyl agent create create an agent, guided — name, harness, model, permissions, project (flags answer any question up front) daktyl agent attach attach to an agent's terminal (harnesses that have one) daktyl agent kill stop one agent (local first, hub fallback) daktyl agent role read or set an agent's role (leader, owner:app, worker) — what `role:` targets resolve to; `none` clears options: --host H create on another registered machine (skips attach) --harness H which harness to run (default claude-code) --model M pin the model at launch --effort L pin the effort level at launch --project P launch inside a registered project --role R pin its role at creation (leader, owner:app, worker) --bypass / --no-bypass launch with or without --dangerously-skip-permissions --ephemeral keep no history after it stops: identity, artifacts and hub rows dropped on kill everything: daktyl --help ### daktyl project usage: daktyl project the projects this machine hosts daktyl project ls the projects this machine hosts, and who is running in each daktyl project add register a project: `add [path] [id]` — no path registers $PWD daktyl project rm unregister by id (prompts if agents are running there) options: --yes rm: skip the confirmation --keep-agents rm: unregister but leave running agents alone everything: daktyl --help ### daktyl keys usage: daktyl keys pinned owner signing keys daktyl keys list the owner signing keys pinned on this machine daktyl keys add pin an owner pubkey: `add [label]` daktyl keys remove unpin by kid or pubkey daktyl keys pair QR-scan trust bootstrap with the phone daktyl keys fingerprint show the kid/fingerprint for a pubkey everything: daktyl --help ### daktyl machine usage: daktyl machine this computer and the fleet it belongs to daktyl machine ls list registered computers (and the build each reports) daktyl machine update roll the published CLI onto hosts through the hub: `update --all | …` (`--wait ` reads back what each reports) daktyl machine doctor read-only health check of this machine daktyl machine retention what auto-deletion WOULD do: `retention [status|keep|unkeep ]` daktyl machine uninstall remove the CLI (see `uninstall` below) everything: daktyl --help ### daktyl attach usage: daktyl attach attach to an agent — its tmux session if it's local (Ctrl-b d to detach), else the chat REPL (harness seats, other hosts) everything: daktyl --help ### daktyl chat usage: daktyl chat open a live terminal chat with a running agent (like the app's Live tab) everything: daktyl --help ### daktyl create usage: daktyl create create an agent, guided — name, harness, model, permissions, project; any question answered by a flag is not asked, so a fully-flagged invocation is scriptable and needs no terminal options: --host H create it on another registered machine --harness H which harness to run (default claude-code) --model M pin the model at launch --project P run it inside a registered project --bypass / --no-bypass run tools without asking / ask first everything: daktyl --help ### daktyl kill usage: daktyl kill stop one agent — local tmux first, hub fallback options: --all stop every agent on this host (confirms; --yes skips) --yes skip the confirmation everything: daktyl --help ### daktyl connect usage: daktyl connect [name] sign in + register this computer + start its daemon (skips what's done) everything: daktyl --help ### daktyl init usage: daktyl init [name] register this computer and set it up: channel plugin, login supervisor, default project, daemon — not signed in? shows a QR to scan with the app options: --dev developer machine: the plugin from that checkout's mcp/claude-channels, and it becomes the default project --project the default project agents start in --no-setup register only (plus the daemon phase); skip plugin, supervisor and project --rekey re-register even though this computer already is (rotates the host key; the daemon reconnects) everything: daktyl --help ### daktyl status usage: daktyl status hub health, identity, registered machines everything: daktyl --help ### daktyl fleet usage: daktyl fleet every agent and seat across the fleet — state, model, context, freshness everything: daktyl --help ### daktyl usage usage: daktyl usage an agent's token/context history (what the app's chart draws) everything: daktyl --help ### daktyl probe usage: daktyl probe [message] send one message AS YOU and wait for the reply (+ the turn's telemetry) everything: daktyl --help ### daktyl daemon usage: daktyl daemon [start|stop|status] this host's daemon — heartbeats to the hub + executes fleet actions daktyl daemon start start it in the background (bare `daktyl daemon` does the same) daktyl daemon stop stop the background daemon daktyl daemon status running? where's the log? does it survive logout? options: --foreground run in this terminal (what systemd and tmux use) --allow-sibling start beside a live daemon anyway (they BOTH execute every command) everything: daktyl --help ### daktyl update usage: daktyl update self-update the CLI + channel plugin from the hub (sha256-verified) options: --check report what's available, change nothing --force reinstall even when the commit matches everything: daktyl --help ### daktyl uninstall usage: daktyl uninstall remove the CLI options: --all also stop the daemon + agents, deregister, remove plugin + config --yes skip the confirmation everything: daktyl --help ### daktyl doctor usage: daktyl doctor read-only health check of this machine everything: daktyl --help ### daktyl logs usage: daktyl logs the daemon's log: `logs [-n 200] [--since 15m] [--level warn] [-f] [--json]` (reads across rotation; pipe it anywhere) everything: daktyl --help ### daktyl completion usage: daktyl completion bash|zsh print a shell-completion script: eval "$(daktyl completion bash)" everything: daktyl --help ---- # Harnesses Claude Code, Codex, Copilot, opencode, Hermes, Antigravity, Cursor — equals. Source: https://daktylconnect.com/docs/harnesses.html A harness is the coding agent itself. Daktyl seats each one the same way and shows it on the phone the same way: same chat, same status, same calls, same approvals. There is no first-class harness. ## Built in These adapters ship inside the daemon. The table is read out of daktyl-cli/src/daemon/adapters/*.mjs when this page is generated, so it cannot drift from the code. Harness | Shape | What that means antigravity | stream | one long-lived process per seat; a turn is a line in and the reply streamed out claude-code | pane | drives a real terminal session you can attach to claude-headless | turn | one process per turn; the daemon feeds it prompts and reads the reply claude-sdk | sdk | an in-process SDK session; the model switches live codex | turn | one process per turn; the daemon feeds it prompts and reads the reply cursor | acp | speaks the Agent Client Protocol over a pipe opencode | acp | speaks the Agent Client Protocol over a pipe ## Adding one is configuration Any harness that speaks the Agent Client Protocol is a block in ~/.daktyl/config.json — no new code, no release. Hermes, Copilot and opencode are seated exactly this way on live hosts today: "adapters": { "hermes": { "kind": "acp", "argv": ["hermes", "acp"] } } A name the build does not know is refused by name — never silently mapped to another harness. ## Setting one up Install the harness and sign in to it on the machine; the daemon finds it and seats it. Daktyl never installs a harness, signs in to one or holds its keys. The table is read out of the adapters: the binary each one looks for, the variable that points it somewhere else, and the hint the daemon gives when it cannot find it (where it gives one). Harness | Looks for | Override | When it is missing antigravity | agy | DAKTYL_AGY_BIN | install Antigravity, or set DAKTYL_AGY_BIN to its path claude-code | claude | DAKTYL_CLAUDE_BIN | claude-headless | claude | DAKTYL_CLAUDE_BIN | install Claude Code, or set DAKTYL_CLAUDE_BIN to its path claude-sdk | claude | DAKTYL_CLAUDE_BIN | codex | codex | DAKTYL_CODEX_BIN | install the Codex CLI, or set DAKTYL_CODEX_BIN to its path cursor | cursor-agent | DAKTYL_CURSOR_BIN | install the Cursor CLI (cursor-agent), or set DAKTYL_CURSOR_BIN to its path opencode | opencode | | install opencode, or set its argv in adapters.opencode With one harness installed, an agent started without naming one uses it. With several, name it: daktyl create --harness codex. ### Claude Code (claude-code, claude-sdk, claude-headless) One claude binary, three ways of driving it; an unnamed start uses the terminal one, claude-code. Install Claude Code and run claude once in a terminal to sign in. The terminal harness runs inside tmux, so install tmux as well (brew install tmux, or sudo apt-get install -y tmux); daktyl attach opens a running agent's session. It also needs the channel plugin the installer puts in place — without it the harness is reported as not present rather than launched deaf. On macOS, claude-sdk signs in through the login Keychain, so the daemon has to run in your login session. Where it cannot reach the Keychain it refuses the seat and says so. ### Codex Install the Codex CLI and sign in with codex login (codex login status tells you whether you are). Each turn is one codex exec in the project directory. The Daktyl tools are passed to every turn on the command line, so nothing needs adding to ~/.codex/config.toml. A signed-out Codex shows as blocked on sign-in, not as a crash. ### Cursor Install the Cursor CLI (cursor-agent) and sign in with cursor-agent login. On a machine with no browser, NO_OPEN_BROWSER=1 cursor-agent login prints a link you can approve on your phone. The CLI's sign-in is separate from the Cursor editor's. Daktyl runs it as cursor-agent acp; a Cursor seat stays on the model it started with (no live model switch) and has no compact. ### Antigravity Install Antigravity so that agy is on the path, and sign in to it once. On macOS its credentials live in the login Keychain, so the daemon has to run in your login session; where it cannot reach the Keychain the harness is reported as not probed, with the reason. One agy process stays up per seat between turns. Antigravity accepts a conversation id it does not know and quietly starts a new conversation, so Daktyl checks the id every reply carries against the one it asked for, and a resume that forked is an error rather than a fresh conversation passed off as the old one. ### opencode Built in, run as opencode acp. Give opencode a provider itself (its own sign-in or a provider key). The models a seat may switch between are the ones declared in the opencode.json of the directory named by adapters.opencode.cwd (provider..models, plus its model); opencode's own catalog also lists models merged in from elsewhere that may never have been pulled, so only the declared ones are offered. Effort is written into that file as the model's reasoningEffort and applies on the next restart. An agent started in a registered project runs there; otherwise it runs in that directory. "adapters": { "opencode": { "cwd": "/home/you/work" } } ### Hermes Seated by configuration, with the block shown above. Set its model and provider in Hermes itself. It has no effort control over ACP. When Hermes declares no model option, the block's own model is what the phone shows. ### Copilot (advanced setup) The GitHub Copilot CLI speaks ACP and is seated by configuration too ("copilot": { "kind": "acp", "argv": ["copilot", "--acp"] }), after you sign in to it. It ignores the MCP servers an ACP client declares, so a Copilot seat chats but has no Daktyl tools unless you add the Daktyl server to ~/.copilot/mcp-config.json yourself. ## Capabilities Harnesses differ, and Daktyl says so rather than pretending. Each seat reports what it can do, and the app gates its controls on that: a button you can see is a button that works. The vocabulary is frozen — an adapter may claim native (the harness does it), emulated (Daktyl does it around the harness) or unsupported; a capability the seat does not mention is unknown, not no. Capability | What it gates status | live state on the phone (thinking, running, idle) context | the context ring and token telemetry model | switching the model from the app effort | reasoning-effort level permission_mode | the tool-approval mode picker thinking | extended thinking on or off compact | compacting the conversation interrupt | stopping a turn mid-flight plan | plan mode approvals | tool approvals reaching your lock screen resume | resuming the same conversation after a restart call | joining a voice call steer | sending a message while a turn is running project | launching inside a registered project directory tools | per-tool-call activity in the timeline diffs | working-tree changes as a diff on the phone restart_free_model_switch | whether a model switch keeps the process alive ## Choosing one daktyl create --harness codex --model gpt-5 --project my-repo daktyl agent ls # what is running here, panes and seats daktyl fleet # everything, everywhere, with model and context ---- # Agent policy Two switches per agent: may it talk, may it manage. Source: https://daktylconnect.com/docs/agent-policy.html Permissions come in two separate layers, and mixing them up is the usual mistake. ## Autonomy — what an agent may do to your machine One picker on the agent, a ladder from cautious to trusting: plan → manual → edits → auto → bypass. Bypass is the top rung of the same ladder, not a separate switch. Which rungs exist depends on the harness (the permission_mode capability); the app only shows the ones the seat actually supports. When an agent stops to ask, the request reaches your phone: approve or deny straight from the notification or the lock screen. ## Agent policy — what an agent may do to your other agents Switch | Off means | Default talk | the agent may not open or reply to peer threads, and may not be a target of one. You can always message it. | on manage | the agent may not start, stop, restart, re-model, compact or otherwise command another agent. Acting on itself is always allowed. | off Both are enforced at the hub, not in the app: a blocked call comes back 403 with the reason, so an agent cannot route around the UI. manage is the one thing standing between a prompt-injected agent and "stop the whole fleet", which is why it is off by default. ## Inheritance When one agent starts another, the new agent copies the starter's autonomy and policy — one account-level switch, on by default. The copy happens at start and then the two are independent; there is no live link. Every start also records who started it, whether inheritance is on or off. Channel messages are untrusted input. An agent should never grant access, pair a device or reveal a secret because a message asked it to — and with manage off it cannot command your other agents even if it tries. ---- # Voice calls Ring an agent, or let it ring you. Source: https://daktylconnect.com/docs/calls.html A call is a real full-screen call on your locked phone — it rings, you swipe, you talk. Either side can start one: you ring an agent from the app, or an agent rings you when it needs you. ## How a call goes - You speak; the turn is transcribed and delivered to the agent as a message. - The agent's reply is spoken back to you. You can interrupt it — barge in and it stops. - The whole exchange lands in the feed as a transcript afterwards, so nothing is lost to audio. - A call runs hands-free over CarPlay, AirPods or the speaker. ## When a call ends Every call ends with a stated reason, and the agent is told which: you hung up, the connection dropped, the line went silent, or it never connected. An agent knows the difference between "he hung up on me" and "the tunnel died", so it can pick up sensibly next time. ## Liveness Both ends heartbeat while a call is up. A brief network stumble is ridden out on a grace window and then retried; only after the retries are exhausted is the call declared lost. The hub is the referee and is always the last to give up, so the two ends never disagree about whether a call is still alive. Not every harness can join a call — the call capability says which, and the app only offers the button where it works. See Harnesses. ---- # Photos Send a picture; the agent reads it on its own machine. Source: https://daktylconnect.com/docs/photos.html Share a photo or a screenshot with an agent from the phone and it arrives as part of the conversation — a design on a napkin, a stack trace on someone else's monitor, a photo of a board. ## Where the bytes go The phone uploads to the hub; the hub tells the agent's own machine to fetch it, and the daemon pulls the bytes down with that machine's host key and drops them in a local folder. The agent then opens an ordinary local file with its ordinary file tools — which is why this works for an agent on your desktop and not just one running next to the hub. ## What that means for you - The agent can actually read the image, whatever machine it is on. - The file lands on your hardware, not only in someone else's storage. - Any harness benefits — the fetch is done by the daemon, not by the harness. ---- # Tunnels Open a port on a machine, tap it on your phone. Source: https://daktylconnect.com/docs/tunnels.html An agent starts a dev server on the machine it is working on. You tap it on your phone and the page opens — a React app on the desktop, a notebook on a cloud box, a preview of the thing that was just built. ## How it works The page runs in your phone's browser and speaks directly to the machine over an encrypted peer-to-peer data channel. A service worker on the page catches every request and sends it down that channel; a small helper process beside the daemon answers it out of localhost:PORT. The hub only introduces the two ends — it exchanges the connection details and then steps out. Your traffic never flows through our servers, which is a design constraint, not a phase: video, large files and busy pages cost us nothing and are not throttled by us. ## What it does and does not do - Serves whatever is already listening on that port. Daktyl never starts your server for you — if nothing is listening you get one sentence saying so, naming the port. - The tunnel is for you, the owner, viewing your own machine. Public share links are not V1. - Open ports are listed per machine in the app, under the machine, and can be closed from there. Direct peer-to-peer connections do not always land — a carrier network behind CGNAT is the hard case. When it cannot connect you are told, rather than left with a spinner. ---- # Triggers Let CI, a monitor or a cron job hand an agent a prompt. Source: https://daktylconnect.com/docs/triggers.html A trigger is a named webhook bound to one agent. Something outside your fleet — a CI job that just failed, an uptime monitor, a nightly cron — sends it a prompt, and the agent gets to work on it with nobody at the phone. ## Make one In the app, open More → Triggers and create a trigger: give it a name (the thing that fires it, such as ci-failures) and the agent it goes to. The target can be an agent's name or a role such as role:leader, which follows whichever agent holds that role when it fires. The app shows the trigger's token once; store it where the caller keeps secrets (a CI secret, for example). The hub keeps only its hash. ## Fire it curl -X POST https://app.daktylconnect.com/triggers//fire \ -H "Authorization: Bearer $TRIGGER_TOKEN" \ -H "Content-Type: application/json" \ -d '{"prompt": "The nightly build failed on main. Read the log and fix it."}' The answer is {"ok": true, "delivered": true, "agent": "…"}. delivered is false when the agent is not connected right now; the prompt is not queued for later. ## What the agent and you see - The prompt arrives from trigger:, never as you, so an agent can always tell a webhook from a person. - Your feed shows a line saying the trigger fired, with the start of the prompt. - The Triggers page shows each trigger's target, how many times it fired, and when it last did. ## Limits and safety - A token fires its own trigger and nothing else. It cannot read anything or reach another agent. - A prompt over 4,000 characters is refused, not cut short: a shortened prompt is one the caller did not write. Each trigger fires at most 30 times a minute. - Reassigning a trigger to another agent, or renaming it, keeps its token, so the secret in CI never has to change when your fleet does. Deleting a trigger revokes its token at once. - Trigger prompts are not end-to-end encrypted: the hub carries them in the clear to your agent. Do not put secrets in a prompt. ---- # Local models Bring your own endpoint. This page is the support contract. Source: https://daktylconnect.com/docs/local-models.html Local models are supportable when the boundary is clear. This is that boundary: anything on this page is supported, anything not on it is not. ## What Daktyl does and does not do - You run the model server. Daktyl never starts, stops, installs or manages an inference server. It is your process, your unit file, your GPU. - You point the harness at it. The harness is configured with an OpenAI-compatible endpoint — a base URL, a model id, optionally a key. Daktyl reads that config; it does not write it. - Daktyl only checks it answers. Switching a seat to a local model probes the endpoint once. If nothing answers, the switch is refused with one sentence ("llama.cpp on 127.0.0.1:8080 isn't running — start it, then switch again") and the seat stays on the model that works. If something else holds the port, the sentence names it. - Telemetry needs a context limit. Give a custom model a context limit and the context ring works. Without one, Daktyl shows no stats rather than wrong ones. ## Wiring the probe Per harness, in ~/.daktyl/config.json, keyed by the model id's provider prefix. A provider that is not in the map is never probed and the switch behaves as before. "local_endpoints": { "llamacpp": { "url": "http://127.0.0.1:8080/v1/models", "label": "llama.cpp" } } ## A recipe that works llama-server -m Qwen3.8-27B-Q4_K_M.gguf --alias qwen3.8-27b \ --jinja -c 32768 --host 127.0.0.1 --port 8080 Then a provider row in the harness pointing at http://127.0.0.1:8080/v1. Reasoning traces are split off by the server's default reasoning format, so a model's private thinking is never spoken aloud on a call. Some local models are fine for text and poor for voice — a model that pauses for ten seconds before its first token makes a bad phone call. Test on a call before relying on one. ---- # Development workflow How work actually flows through a fleet of agents. Source: https://daktylconnect.com/docs/workflow.html Running several agents at once is a workflow problem before it is a tooling problem. This is the loop that works in practice; nothing here is enforced by the product, it is how to use it. ## The loop Leader -> Worker tasking (the ticket is claimed first; the worker owns the checkout) Worker -> Leader design (what it will change, where, the failing test) Leader -> Worker approval (or revision turns until approved) Worker -> Leader completion (branch + SHA, gates run, what was NOT done) Leader -> Reviewer review kickoff (a FRESH agent, read-only, on the diff) Reviewer -> Leader findings (ranked, most severe first, a concrete failure case each) Leader -> Worker relay (the reviewer never talks to the worker) Worker -> ship build, deploy, verify by effect ## Why it is shaped that way - One agent per checkout. Two agents editing one working tree steal each other's uncommitted work. Give each a checkout, or hand the checkout over explicitly. - The reviewer is a fresh agent, every time. Never the author reviewing itself, and never the one who approved the design — it shares the blind spot. The best review outcome is usually a deletion from the plan. - Size the model to the task. A mechanical sweep does not need your most expensive model; a security change does. - Verify by effect. "The code is deployed" is not a result. Measure the thing the change was supposed to do, on the live system, and record what you measured. - The handoff sentence is the one nobody reviews. Make it name every behaviour it claims, and say plainly what was skipped. ## What each message carries Tasking: the ticket, the checkout and branch, the gate to run, what "done" looks like as an observable effect, and the constraints that actually bite. Design: files touched, the failing test first, what it deliberately does not do. Completion: branch and SHA, gates with their real exit codes, anything skipped. ---- # FAQ The questions that come up first. Source: https://daktylconnect.com/docs/faq.html ## What does it cost? V1 is free — the whole product, no tiers, no card, as many machines and agents as you like. ## Do you store my code? No. Your agents run on hardware you own and your work stays there. The hub coordinates machines and carries messages; it does not host your repositories and there is no cloud backup, by design. ## Do I have to open a port or set up a VPN? No. Every machine dials out to the hub and nothing listens for inbound connections. A NAT'd desktop, a cloud box and a laptop on hotel wifi all work the same way. ## Which agents does it work with? Claude Code, Codex, Copilot, opencode, Hermes, Antigravity, Cursor and any harness that speaks the Agent Client Protocol — that last group is added by configuration, not by us shipping a release. See Harnesses. ## Which operating systems? Linux and macOS for the machines. Windows works under WSL today; native Windows comes later. The cockpit app is iOS. ## Where do I get the app? TestFlight during the preview. ## Can I use my own model? Yes — point a harness at an OpenAI-compatible endpoint on your own hardware. See Local models. ## What happens when an agent needs permission? It reaches your phone. Approve or deny from the notification or the lock screen without opening the app. How often that happens is up to the autonomy level you set — see Agent policy. ## What if an agent goes rogue? An agent cannot command your other agents unless you turn manage on, and that is enforced at the hub rather than hidden in the app. Kill anything from your phone, or daktyl kill --all on the machine. ## Does a restart lose the conversation? No. Restart an agent and it resumes the same conversation; past sessions stay resumable across a crash or a reboot. ## Is there an API? The hub publishes its own contract at https://app.daktylconnect.com/openapi.json (authenticated). Model-readable docs are at llms.txt and llms-full.txt. ---- # Privacy What leaves your machines, and what does not. Source: https://daktylconnect.com/docs/privacy.html ## Where your work lives Your agents run on computers you own. Their code, their repositories and their working files stay on those machines. Daktyl Connect does not copy, host or back up your work — there is no cloud backup, by design. ## What the hub holds The hub is a coordinator. To do that it holds: your account identity (a Google sign-in), the list of machines and agents you have registered, the messages exchanged between you and your agents, status and usage telemetry the app draws, and photos you deliberately send to an agent. Voice-call audio is transcribed and the transcript is kept with the conversation. ## What it does not hold - Your source code, unless an agent sends you a piece of it in a message. - Tunnel traffic. A tunnel is peer-to-peer between your phone and your machine; the hub introduces the two ends and nothing more. - Anything from another account. Accounts are isolated from each other. ## In transit All traffic between the phone, the machines and the hub is encrypted in transit. Every machine dials out; nothing accepts inbound connections. ## Deleting things Conversations and sessions can be removed from the app, and machines can be unregistered from the app or with daktyl machine. Deleting your account removes your account's data from the hub. ## Who we are and how to reach us Daktyl Connect is a product of Daktyl Labs LLC. Questions about your data, or a request to see or delete it: admin@daktyllabs.com. This page describes the invite-only preview and will be replaced by a formal policy before general availability. ---- # Terms of Service The basics, while the service is in preview. Source: https://daktylconnect.com/docs/terms.html ## Accepting these terms Using Daktyl Connect means accepting these terms. If you do not accept them, do not use the service. This is an initial version written for the invite-only preview; it will be expanded before general availability. ## What the service is Daktyl Connect lets you reach coding agents running on computers you own. The hub coordinates: it carries messages between your phone and your machines, relays voice calls, and holds the account and status information the app draws. Your agents, your code and your machines remain yours — see Privacy for what the hub does and does not hold. ## Your account and acceptable use You sign in with Google and you are responsible for what happens under your account, including the agents you start and the machines you register. Keep your sign-in and your machine credentials to yourself. - Use the service lawfully, and only on machines you are entitled to control. - Do not use it to attack, overload or gain unauthorised access to anything. - Do not attempt to reach another account's machines, agents or messages. Accounts that break these rules may be suspended. ## Availability and changes This is a preview. Features may change or be removed, and the service may be unavailable at times. We may change these terms; the current version always lives at this address, and continuing to use the service after a change means accepting it. ## No warranty The service is provided as is, without warranties of any kind, express or implied. We do not warrant that it will be uninterrupted, error-free, or that it will suit any particular purpose. Your agents act on your machines; you are responsible for what they do there, and for keeping your own backups. ## Limitation of liability To the extent the law allows, Daktyl Labs is not liable for indirect, incidental or consequential damages, or for lost data, lost profits or lost work arising from your use of the service. ## Ending it You may stop using the service and delete your account at any time from the app. We may suspend or end access to the service, for a single account or altogether, particularly during the preview. ## Contact Daktyl Connect is a product of Daktyl Labs LLC. Questions about these terms: admin@daktyllabs.com. An initial version for the invite-only preview. It will be replaced by fuller terms before general availability.