Cyrus: a self-hostable background agent that watches Linear, GitHub, GitLab and Slack

The problem Cyrus targets: issue trackers that cannot run code

A tracker issue is a description of work. Nothing in Linear, GitHub Issues, GitLab or Slack executes that description. The usual bridge is a human who reads the issue, opens an editor, creates a branch, and pastes context into a coding agent. Cyrus removes the human from the middle of that loop by watching for issues assigned to it, creating a Git worktree per issue, and running a coding harness session inside that worktree. The README describes the flow as monitoring issues assigned to it, creating isolated Git worktrees for each issue, running sessions to process them, and streaming detailed agent activity updates back to the tracker, including dropdown selects and approvals. The audience is engineering teams that already route work through one of those four trackers and want the agent to appear as a participant in the tracker rather than as a separate tool someone has to remember to open. The BYOK note matters here: Cyrus is a bring-your-own-keys platform for tokens, so the model spend stays on your account and the project supplies orchestration, not inference.

Worktrees as the isolation unit, and why that choice matters

The mechanism the README commits to is one Git worktree per issue. A worktree is a second checkout of the same repository attached to a different branch, sharing the object store but with its own working directory. That gives each agent run a filesystem it can modify without disturbing the main checkout or any other concurrent run. It also means the agent's edits are ordinary Git state: a branch you can inspect, diff, push or discard. The alternative design, cloning the repository per task, costs disk and network on every run; a shared checkout with branch switching costs correctness when two runs overlap. Worktrees sit between those. The README does not state how worktrees are cleaned up after a run finishes, or what happens when a run fails mid-edit, so treat cleanup as something to verify in your own deployment rather than something the documentation promises. The second half of the loop is the return path: activity updates stream back into Linear or GitHub, and the README mentions interaction primitives such as dropdown selects and approvals, which implies the agent can pause and ask rather than running to completion unsupervised.

Harnesses: Claude Code, Codex, Cursor, Gemini, Opencode

Cyrus does not ship its own model loop. It drives an existing coding harness, and the README lists Claude Code, Codex, Cursor, Gemini and Opencode as the options. That is a meaningful architectural decision: the project's job is scheduling, isolation, tracker integration and status reporting, while the harness owns the reasoning and tool use. It also means the quality of any given run depends on which harness you point Cyrus at, and the project's release cadence is partly a function of other people's CLIs. The README does not explain how harness selection is configured, whether it is per-repository or per-deployment, or what the minimum supported version of each harness is. If you are choosing Cyrus because of one specific harness, confirm that combination in the configuration reference before you build a workflow around it. The upside of the design is that swapping harnesses does not require swapping the tracker integration, so a team that standardises on one harness today is not rewriting its Linear setup if it changes its mind later.

Two deployment paths, and the difference between them

The README splits installation into a community end-to-end path and a paid path, and the distinction is not just support. The community route is described as zero cost and self-hosted in full: your own Linear OAuth app, GitHub App and Slack App, with an AI-guided setup skill that installs dependencies, configures auth, creates the integration apps and connects repositories. The command is npx skills add ceedaragents/cyrus -g, followed by /cyrus-setup inside any AI coding agent. A manual guide lives at docs/SELF_HOSTING.md. The paid route reverses part of that. The README is explicit that paid self-hosted deployments are called self-hosted because they use a machine you control as the agent runtime, while the networking layer and integrations are provided by the Cyrus cloud provider. Installation is npm install -g cyrus-ai followed by cyrus auth <your-token>, with the token supplied during onboarding. So the paid product is not a hosted agent; it is a hosted integration and networking tier in front of an agent you still run. Teams that read self-hosted as no third party involved should read that paragraph twice.

Getting it running: commands, process management and Git credentials

For the community path, the two commands in the README are npx skills add ceedaragents/cyrus -g and then /cyrus-setup from inside an AI coding agent. The setup skill is documented as handling dependency installation, auth configuration, integration app creation and repository connection, which is a lot of surface area to delegate to a generated setup flow. Manual configuration is documented in docs/SELF_HOSTING.md, and the configuration file itself is described in docs/CONFIG_FILE.md under Configuration Reference. For the paid path, npm install -g cyrus-ai installs the CLI and cyrus auth <your-token> authenticates it. Cyrus has to stay running, and the README gives three options: tmux new -s cyrus followed by running cyrus and detaching with Ctrl+B, D; pm2 start cyrus --name cyrus; or systemd, with the unit file guidance in the Running as a Service section of docs/SELF_HOSTING.md. To open pull requests or merge requests, Git and your hosting CLI must be configured, per docs/GIT_GITHUB.md or docs/GIT_GITLAB.md. There are further documents for Zulip mentions and DMs, Cloudflare Tunnel for exposing a local instance, and repository and global initialization scripts in docs/SETUP_SCRIPTS.md.

Where Cyrus is the wrong tool

The clearest limitation is the runtime model. Cyrus is a long-lived process on a machine you control, whether that is tmux, pm2 or systemd. If nobody owns that machine, the agent stops responding to issues and the failure is silent from the tracker's perspective, because the tracker only sees the absence of updates. A team without anyone who can look at a process list should not take this on. The second constraint is the BYOK arrangement. Cyrus does not supply tokens, so cost control, rate limits and key rotation are your problem, and the README frames this as a platform characteristic rather than a temporary state. The third is scope: the README covers Linear, GitHub, GitLab and Slack as the tracker surfaces, with Zulip mentioned as an additional document, so a team on Jira or Azure DevOps is outside the described surface. Finally, the documentation set is broad but uneven. Worktree cleanup, harness version requirements and the exact behaviour when an approval is declined are not spelled out in the README, and the configuration reference is a separate file, which suggests the README is intentionally a map rather than a manual.

The alternative worth comparing: a CI-triggered agent job

The obvious comparison is not another chat-driven agent but the CI job you could already write. A GitHub Actions or GitLab CI workflow triggered by a label can check out the repository, run a coding harness against the issue body, and open a pull request with the result. The mechanism differs in three ways. CI gives you a fresh, disposable runner per task, which sidesteps the worktree cleanup question entirely, at the cost of a full checkout each time and a cold start. CI is event-driven and stateless: it does not monitor for assignments continuously, so it cannot hold a conversation in the issue thread or wait for an approval mid-run. And CI is bounded by the workflow's timeout and permissions model, which is a tighter sandbox than a persistent process on your own machine. Cyrus's advantage is the interactive loop back into Linear or GitHub, including the dropdown selects and approvals the README mentions. If your work does not need that loop, a CI job is less infrastructure to keep alive. If it does, Cyrus is doing something a workflow file cannot easily express.

Licence, maintenance cost and what to check before adopting

Cyrus is Apache-2.0, which permits commercial use, modification and redistribution provided the licence and notices are preserved, and it includes a patent grant. That is a permissive licence, and it does not cover the harnesses Cyrus drives, the trackers it connects to, or the model tokens, each of which carries its own terms. This is not legal advice; if you are redistributing a modified Cyrus inside a product, have counsel read the NOTICE handling. On maintenance, the release history shows v0.2.71, v0.2.70 and v0.2.69 within roughly two weeks of each other in late August and early September 2026, which indicates active iteration on a pre-1.0 version. Pre-1.0 plus frequent releases means upgrade churn is a real line item: pin the version you deploy rather than tracking latest, and read the release notes before moving. The Apache-2.0 grant means you can fork if the project's direction diverges from yours, but forking a project that integrates with four trackers and five harnesses is a substantial commitment. The concrete things to verify first are the harness you intend to run, the Git and hosting CLI credentials described in docs/GIT_GITHUB.md or docs/GIT_GITLAB.md, and whether the paid tier's cloud-provided networking layer is acceptable for your repository access.

Editorial conclusion

Adopt Cyrus if your team already lives in Linear, GitHub, GitLab or Slack and you want issue-driven agent runs on a machine you control, with the community path giving you the integrations and the paid path giving you the networking layer. Do not adopt it if you want a fully managed service with no runtime to babysit, or if you cannot run a long-lived process. Before committing, verify that the harness you intend to use is actually supported, that your Git and hosting CLI credentials are in place per docs/GIT_GITHUB.md, and that you are comfortable with the BYOK token arrangement, since Cyrus supplies the orchestration and not the model access.

Official sources

1. cyrusagents/cyrus on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases