Collie turns the URL into a root login, and says so in the README

The dashboard is ordered by what is blocking you

The interface inverts the usual terminal layout. The status dashboard is led by what needs your input, and every other pane sits underneath under its own workspace, with the tab on the row so you can tell which context you are looking at. Below that are the views that matter on a phone: Ask, where the agent's own prompts become tappable buttons rather than something you type back; Space, showing tabs and panes and deep-linkable; Keys, a special-keys pad covering Esc, Ctrl+C, arrows and modifier combinations so there is nothing to remember as a chord; Quick, holding your own one-tap replies from `quick-replies.toml`; and Settings for appearance, language and typeface, all per device. Long-press a pane pill or a tab chip to rename or close it, and hold a row or right-click it to pin that pane to the top.

Device pairing is the write credential, not a login

The authorisation model is unusual enough to be worth stating plainly. Device pairing is the write credential: once a device is paired, every write needs its token. There is no account system and no password, because there is no user model to log into, which follows from the single-user design. Push notifications arrive when an agent blocks on user input, and quick actions plus slash commands are configured per agent rather than globally. File attachments accept images from the camera roll plus markdown, text and code files. The input box is an ordinary text field, so system voice dictation works without any special handling, and built-in voice input exists as a separate feature that stays disabled until you configure it explicitly.

The install script verifies a checksum and never asks for sudo

Installation is one command run on the host, not on the phone:

curl -fsSL https://colliepwa.dev/install.sh | sh

The requirements are named and modest: `curl`, `tar`, and a sha256 utility, with no compiler toolchain and no request for `sudo`. The script downloads the latest release for your platform, verifies the sha256 checksum, installs the files, puts `collie` on your PATH, and then prints the remaining manual steps rather than pretending the install is finished. That checksum step is the part worth caring about, since the alternative to a package manager is usually a binary fetched over a pipe with nothing to check it against. There is also a five-minute install guide for people new to Tailscale or Herdr, and the version numbers move quickly: 1.15.1 and 1.15.2 on 2026-10-01, 1.15.3 on 2026-10-02.

The bridge binds loopback, and one flag disables the gates

The example configuration shows the intended shape and the escape hatch at the same time. `COLLIE_PORT` is 8787 and `COLLIE_HOST` is 127.0.0.1, with a comment that tailscale serve proxies to it. Then the warning: a non-loopback value refuses to start unless you also set `COLLIE_ALLOW_NON_LOOPBACK_BIND=1`, and in that case the identity, device and same-origin gates become client-settable. Read that as one sentence. The bind address is not just a network choice; it is what makes three of the security checks meaningful, and one flag converts them from enforced to optional. There is a second escape hatch for reverse-proxy setups, where skipping tailscale serve entirely is allowed, but that also means `COLLIE_TRUSTED_USER` has no effect because nothing is injecting the identity header.

funnel is the one thing the README forbids outright

The security section is the strongest part of the documentation and it opens by stating the risk instead of burying it. Collie provides remote shell access to your machine by design, and a single API call sends arbitrary keystrokes directly into a live terminal pane. Anyone with access to the URL can read pane output, which means source code, secrets, environment variables and agent output, and can execute arbitrary commands with your full user privileges. There is no sandbox and no command allow-list, and the reason given is that both would defeat the core workflow, which is a fair argument and an honest trade. The instruction that follows is to treat the URL as a root login: bind it strictly to the tailnet, set `COLLIE_TRUSTED_USER`, and pair only the physical phone you are using.

Herdr is the supported target; tmux and zellij are one person's testing

The multiplexer support is tiered and the lower tier is labelled honestly. Collie connects each instance to exactly one multiplexer. Herdr is the primary supported target in version 1.0, and there is a dedicated document for the Herdr mobile client alongside an API reference in the repository. tmux and zellij are described as experimental: both run, but testing is limited to a single operator on one machine, and bug reports are requested including reports of working setups. That is a candid statement of coverage rather than a hedge. It also means the compatibility matrix you can rely on today is one multiplexer, and the fallback path exists but is unproven by anyone but the author. Crews extend the model to several machines' Collies behind one URL with operator-triggered failover, which is where the single-user constraint starts to matter.

Configuration is TOML files, and every one has an example checked in

The repository root is unusually well documented for behaviour, with architecture, design, a multiplexer contract, a crew protocol, a packaging deputy RFC, a trademarks file and separate contributing guides for the harness and for the multiplexer work. Behaviour itself is configured through TOML, and the pattern is that every config file has a checked-in example: `cache-rules.toml.example`, `commands.toml.example`, `keys.toml.example`, `launchers.toml.example`, `quick-replies.toml.example` and `theme.toml.example`, alongside `herdr-plugin.toml` for the plugin manifest. Quick replies, key bindings, cache rules and themes are therefore all data rather than code, which means tuning the app does not require a rebuild. There is a Nix flake and a lock file in the tree as well, so a reproducible environment is a supported path.

The test command is twelve checks in a chain

The manifest runs on Bun and the test script is a single shell chain rather than a test runner, which tells you what the project considers worth protecting. It runs the Bun suites for the bridge, the CLI and scripts, then eight bash suites covering the control script, the CLI, payload links, upstream Bun compatibility, tag checking, flake lock checking and pre-commit, then two packaging suites for the Arch Linux package build and refresh. Two more scripts exist outside the default chain: `harness:drift` and `canary`. Dependencies are thin, with commander, Ink for the terminal UI, qrcode-terminal and React as the runtime set, web-push as an optional dependency, and oxlint configured with zero warnings allowed. TypeScript is pinned to a major version ahead of what most projects run.

Editorial conclusion

Collie earns a place if you run Claude Code, Codex or OpenCode inside a multiplexer and want to unblock an agent from a phone without SSH and tmux attach, which is the exact problem it was built to solve. The phone ergonomics are the argument: a status dashboard ordered by what needs input, the agent's own prompts turned into tappable buttons, a special-keys pad so you stop composing chords, and push notification the moment an agent blocks. Two boundaries to hold. It is single-user with no multi-tenant authentication, and the README says outright not to use it for shared or public access, so a team cannot put it on a shared host without reading the deployment notes first. And the non-loopback escape hatch is real: setting `COLLIE_ALLOW_NON_LOOPBACK_BIND=1` makes the identity, device and same-origin gates client-settable, which means the checks that protect a loopback deployment can be turned into suggestions. Leave the bind on 127.0.0.1 and publish with `tailscale serve`, and never with `funnel`.

Frequently asked questions

Official sources

1. AltanS/collie on GitHub
2. License: MIT
3. Project website
4. README
5. Releases