Kiro Crew

A persistent workspace for development work that self-improves and continues beyond one session.

Kiro Crew is an open source development workspace that runs locally or remotely on your hardware. It is persistent, self-learning, and self-evolving. Work with it from the desktop app, web dashboard, and CLI, or continue the same work through connection tools like Slack and Discord. Your multi-step tasks can run unattended, recurring jobs run on your schedule, and heartbeats monitor systems until something needs attention. Kiro Crew Apps tailor that experience to a specific job, combining a purpose-built interface with agents, skills, schedules, integrations, and backend services.

Quick start · Build from source · Why Kiro Crew · Capabilities · How it works · Security · Install · Telemetry · Docs

You choose how to run Kiro Crew: the desktop app with automatic updates, a one-line install on your machine or a remote host, the Docker image for always-on servers, or a build from source. Every path runs on kiro-cli underneath, so the first launch installs it if needed and guides Kiro device-code sign-in.

The desktop app starts a bundled Gateway when no local Gateway is already running, updates itself on the channel you download, and can connect to a remote Gateway over an SSH tunnel. See the desktop app guide.

• macOS: Stable | Insider | Nightly
• Linux: Stable | Insider | Nightly
• Windows: no desktop build yet, so run the Gateway from a source install and open the dashboard in your browser

Install the prebuilt, SHA-256-verified wheel from the release CDN without cloning the repository or running npm and a local build.

Stable, the default:

curl -fsSL https://download.crew.kiro.dev/cli.sh | sh

Track a faster channel, insider or nightly:

curl -fsSL https://download.crew.kiro.dev/cli.sh | sh -s -- --channel insider

Pin an exact version:

curl -fsSL https://download.crew.kiro.dev/cli.sh | sh -s -- --version 0.1.0

Open http://localhost:5476 and start a conversation. The web dashboard works without messaging credentials. Add Slack, Telegram, or WeCom when you want to continue working with the same agent away from the dashboard. These channels connect outbound, so you do not need to expose the dashboard port publicly.

For always-on servers, the Gateway ships as a public multi-arch image on GHCR:

docker run -d --name kirocrew \
  -p 127.0.0.1:5476:5476 \
  -v kirocrew-home:/home/kirocrew \
  ghcr.io/kirodotdev/kirocrew:stable

See the Docker guide for first-run login, channel tags, and the container security model.

macOS and Linux require Python 3.10+, Node.js 18+, npm, and kiro-cli. The first desktop or dashboard launch can install Kiro CLI on the Gateway host and guide device-code sign-in before chat opens. Windows is supported through a native source install; follow the Windows guide instead of the shell steps below.

# 1. Clone and build Kiro Crew
git clone https://github.com/kirodotdev/KiroCrew.git
cd KiroCrew
make build
source .venv/bin/activate

# 2. Configure, verify, and start
kirocrew setup
kirocrew doctor
kirocrew gateway

Most agent sessions end when the chat closes. Kiro Crew runs continuously on hardware you control and keeps working between conversations.

Persistent. Sessions, memory, schedules, and task checkpoints survive Gateway restarts, and scheduled or reactive work continues without someone at the terminal.

Self-learning. Corrections and task failures become durable lessons. Preferences and project context carry into new sessions.

Self-evolving. Repeated patterns become reusable skills. Memory, lessons, and skills stay visible and editable, so each Kiro Crew grows more tailored to the person and work around it.

Runs where you choose. Your Mac, a local container, or a remote machine you control.

One Gateway, many surfaces. Work directly in the desktop app or web dashboard, or continue the same work from the CLI and messaging surfaces like Slack and Discord.

You can also paste a screenshot and ask what is causing an error. Kiro Crew sends the image to the active Kiro model and keeps the diagnosis in the conversation history.

The complete inventory is in Features and What's New.

flowchart TD
    S["Desktop app · Web dashboard · Slack · Telegram · WeCom · CLI"]
    G["Gateway<br/>access · sessions · memory · schedules · approvals · apps"]
    A["Agent sessions<br/>ACP runtime · kiro-cli · MCP tools · models"]
    S --> G --> A

The Gateway separates where the agent runs from where you work with it. In the desktop app or web dashboard, you can work directly through parallel conversations, files, task runs, approvals, memory, and apps. From Slack, Telegram, WeCom, or the CLI, the Gateway routes your work to managed agent sessions under the same memory, tool, approval, and policy services. Apps extend the dashboard and Gateway APIs with focused workflows.

Each active conversation or background task uses an agent session. Its session provider drives kiro-cli over ACP, streams model and tool events, and preserves conversation state. Depending on the workload, a session is backed by its own ACP process or by a session handle on a shared multiplexed ACP runtime. The Gateway manages these sessions along with scheduling, approvals, memory, security policy, messaging connections, and the dashboard.

The current runtime places the Gateway, agent sessions, ACP processes, and state on the same host. Run Kiro Crew on your Mac, inside a container on your machine, or on a remote Linux host you control. Conversation history, memory, and knowledge indexes remain on that host. Model requests are handled by kiro-cli and follow the account and model configuration you use there.

Gateway. The Gateway is the long-running Kiro Crew process. It routes messages from the desktop app, web, CLI, and the messaging surfaces listed below. It persists session state, injects memory and skills, starts scheduled work, coordinates subagents, brokers approvals, enforces runtime policy, and exposes activity in the dashboard.

Agent sessions. A dashboard conversation or Slack thread maps to an isolated agent session. Scheduled jobs, task runs, Telegram and WeCom conversations, and subagents also use managed sessions. These sessions preserve conversation context and can run concurrently before returning results to a parent session or configured surface.

ACP runtime and turns. Kiro Crew supports both a dedicated kiro-cli ACP process for a session and a shared ACP runtime that multiplexes multiple session handles. During each turn, the session sends a prompt, streams model and tool events, resolves approvals, and returns the final result. An agent session is a logical isolation boundary, not necessarily one OS process.

Use the surface that fits the moment.

Choose how work starts.

Memory, learning, and evolution. Kiro Crew maintains preferences, active project context, decaying history summaries, and durable lessons. Corrections and task failures can change later behavior, while repeated patterns can become reusable skills. In-process embeddings add semantic retrieval for memory and the knowledge library. The stored state remains inspectable and editable from the dashboard. Incognito and temporary session modes let you opt out when a conversation should not persist.

Skills, MCP, and apps. Markdown skills supply reusable workflows and can be loaded only when relevant. The built-in kirocrew-core and kirocrew-cron MCP servers expose task, subagent, learning, messaging, and scheduling tools. You can discover additional MCP servers from Kiro or Kiro Crew configuration. The App Kit adds installable interfaces and domain workflows. Apps can add dashboard pages, use scoped Gateway APIs, subscribe to events, and register lifecycle hooks.

Kiro Crew gives an AI agent real tool access, so the controls are enforced at the runtime boundary instead of relying only on prompt instructions.

• Local by default. The dashboard binds to loopback unless you explicitly configure a network URL. Remote dashboards require token authentication.
• Interactive approvals. Review tool requests in the dashboard, Slack, or Telegram. Session-scoped trust can reduce repeated prompts without changing the underlying deny and sensitive-path controls.
• OS sandbox. On Linux and macOS, kiro-cli can run inside namespace or Seatbelt isolation. Standard, strict, and off modes make the tradeoff explicit. Windows offers no equivalent OS-level layer, so Kiro Crew fails closed there: agent subprocesses are refused rather than run unconfined, until you declare the sandbox_allow_unsandboxed_exec opt-in.
• Sensitive data guards. Kiro Crew blocks direct access to protected paths, strips sensitive environment variables, and redacts credential patterns from output before it reaches a chat surface.
• Denied operations. 137 bundled deny patterns block destructive commands and common exfiltration paths even when a session has broad approval.
• Auditability. Security events and tool activity are recorded for review. Use kirocrew security events, audit, and verify to inspect them.
• Governance ceiling. Optional policy and profile files compose with a tightest-wins model. A running app or agent can narrow the allowed scope but cannot loosen the enterprise ceiling. Inspect it with kirocrew policy show, validate, and explain.

No agent security layer removes the need to protect credentials and review high-impact actions. Avoid pasting secrets or sensitive personal data into a chat. Read the security architecture and use SECURITY.md for private vulnerability reporting.

Installer details. The installer resolves the channel feed, verifies the wheel's SHA-256 against the published manifest, installs through pipx when available or a managed virtual environment at ~/.kiro/crew/venv, and records the channel in ~/.kiro/crew/channel. The channels are stable, insider, and nightly, and KIROCREW_CHANNEL sets the default.

Pin an exact wheel. You can also install one exact wheel directly and pin it to its published SHA-256. Every version directory publishes a SHA256SUMS file next to the wheel, so take the hash for your wheel from there and put it in the URL fragment. pip verifies the hash and does not consult a package index for Kiro Crew itself:

pip install "https://download.crew.kiro.dev/cli/stable/<version>/kirocrew-<version>-py3-none-any.whl#sha256=<sha256>"

Semantic memory. Semantic memory needs no setup. Embeddings run in-process, and the Gateway downloads its embedding model in the background on first start, verifies it, and stores it under ~/.kiro/crew/models. Until the model lands, memory search falls back to keyword search and picks up embeddings automatically without a restart. Set KIROCREW_EMBED_MODEL_URL to point at a mirror for airgapped installs.

See Installing and Building for wheels, desktop builds, Windows, optional voice dependencies, and manual setup.

Choose where Kiro Crew runs. The current deployment model keeps the Gateway, agent session runtime, ACP processes, and state together on one host. Your Apps and chat surfaces connect to that Gateway.

For containers, mount the directory selected by KIROCREW_HOME so sessions, configuration, memory, and credentials survive replacement. Keep the Gateway port bound to loopback unless you intentionally configure authenticated remote access. Container isolation and the Kiro Crew OS sandbox are separate layers and depend on the host runtime configuration. See the Docker guide for the published image and deployment details.

Keep it running. Install a systemd service on Linux or a launchd agent on macOS:

kirocrew service install
kirocrew service status
kirocrew logs

The desktop app can use this local Gateway or connect to a remote one. For an always-on VPS, home server, or cloud VM in your account, follow the remote host guide. Kiro Crew does not require a Kiro Crew-hosted control plane.

Configure it. User data lives under ~/.kiro/crew by default. Manage the main configuration with kirocrew config get, set, and edit.

{
  "agent": {
    "provider": "acp",
    "approval_mode": "interactive",
    "sandbox": "auto"
  },
  "session": {
    "timeout_secs": 1800,
    "pool_size": 2
  },
  "dashboard": {
    "bot_name": "Kiro Crew"
  }
}

agent.provider is fixed to acp. Kiro Crew drives kiro-cli over the Agent Client Protocol. Set the dashboard port with KIROCREW_PORT or kirocrew gateway --port <n>. Slack credentials live in ~/.kiro/crew/.env rather than the JSON config.

Troubleshoot quickly. Start with kirocrew doctor. For an ACP timeout, confirm kiro-cli is on PATH and logged in, then allow extra time for the first MCP startup. For memory search, check that the embedding model finished downloading under ~/.kiro/crew/models. For a stale MCP configuration, run kirocrew setup --agent-only, or add --clean to rebuild it.

Find the logs. When you need to debug, the fastest path is kirocrew logs (tail the most recent gateway output) or kirocrew logs -f to follow it live; kirocrew logs -n 200 prints more history. kirocrew logs reads the right source automatically — the systemd journal when the Linux service is installed, the launchd stdout file on macOS, or the foreground gateway log otherwise. Raise verbosity with kirocrew gateway -v (INFO: session lifecycle and context usage) or -vv (DEBUG: full ACP events and message traces); set the persistent default with kirocrew config set agent.log_level, or change it at runtime from the dashboard Logs page. Under ~/.kiro/crew (or your KIROCREW_HOME) you can also read the raw files directly:

See the Troubleshooting guide for the full log-level reference and emergency recovery steps.

Kiro Crew sends one anonymous heartbeat per day so maintainers can see how many copies are actively running, which versions are in use, and which platforms and install channels to support. After a successful install or update from the official app catalog, it also sends one anonymous per-app receipt. Both signals are on by default and use the same controls below.

To turn it off, flip Settings → Privacy → Send anonymous usage heartbeat in the dashboard (the same switch appears on the last step of first-run onboarding). Or from a terminal:

kirocrew telemetry disable        # persists to config.json
export KIROCREW_TELEMETRY_DISABLED=1   # or per-shell / per-container
kirocrew telemetry status         # print exactly what would be sent

The toggle and kirocrew telemetry disable write the same setting, so either one sticks across restarts and upgrades. KIROCREW_TELEMETRY_DISABLED overrides both — when it is set, the dashboard toggle is disabled and says so.

Exactly these five fields are sent, at most once per day, and nothing else:

Official-app install receipts are separate and event-based. After a successful official-catalog install or update, Kiro Crew sends one GET to /b/1/install/<app-slug>?t=<token>&k=<fresh|update>&v=<release> on the same telemetry host. The slug is the public catalog identifier. t is the first 32 hex characters of HMAC-SHA256 keyed by the local beacon install id over app-install:<slug>; the raw install id is never sent, and tokens for different apps cannot be linked to assemble an installed-app profile. k separates fresh installs from updates, and v is the same release-only Kiro Crew version clamp used by the heartbeat.

Receipts are emitted only for bundled or edition-provided official catalog entries. Apps from user-configured registries, local-directory installs, and self-registered apps emit nothing, so private app names never leave the machine. If no persistent beacon install id exists yet, the receipt is skipped.

This list used to be nine fields. Release channel, OS, CPU architecture and governance posture were removed — each was coarse on its own, but the instance id is stable, so those attributes all describe the same copy and together they narrowed the group any one install blends into far more than any single field suggests.

We report this as Daily Active Crews rather than "users": Kiro Crew has no account system of its own, and the Kiro sign-in that kiro-cli uses for model access is never read or sent. There is no way to resolve a copy to a person, so one person running Kiro Crew on three machines counts as three Crews.

Never sent: your prompts, model responses, file contents, file paths, repo or branch names, credentials, environment variables, hostname, username, or IP address. The receiving CDN is configured not to log client IP addresses — the log delivery does not include that field, so no IP is stored at all.

Automatically off in CI, and whenever KIROCREW_HOME points somewhere other than ~/.kiro/crew (dev instances and pods are never counted).

Enterprise administrators can pin it off entirely. A capabilities.telemetry entry in the security policy blocks both outbound signals regardless of the local setting, and the dashboard toggle then says so instead of offering a change that would not take effect:

{"version": 1, "boot": {"fail_closed": true},
 "capabilities": {"telemetry": {"enabled": false}}}

See docs/system-specs/modules/governance.md.

This is separate from telemetry.enabled, which controls local-only performance metrics that never leave your machine. See docs/system-specs/modules/metrics.md.

Contributions are welcome. Create a branch from main, keep changes focused, and run the relevant checks before opening a pull request:

# Backend
pip install -e ".[voice]" --group dev
pytest

# Frontend
cd website
npm ci
npm run check
npm run build

Use GitHub Issues for bugs and feature requests. Do not file security vulnerabilities publicly.

Kiro Crew was made possible by its internal community, the people who supported the project and shipped its code, together with everyone who has since opened a pull request in the open. This is that founding group; as Kiro Crew grows in the open, we look forward to many more contributors joining them. Thank you to everyone who helped make this tool possible:

Listed alphabetically by GitHub username. Internal contributors appear here if they consented to public recognition in the contributor survey; open-source contributors are included from this repository's pull request history. If you contributed and would like to be added, corrected, or removed, please open an issue or a pull request.

Kiro Crew is licensed under the Apache License 2.0. See NOTICE for attribution information.