KiroCrew: an agent workspace that survives the restart

KiroCrew: A Persistent Agent Workspace, Now Documented in Chinese

Most agent sessions die when you close the chat window. That is the problem KiroCrew is built around. It is an open-source development workspace that runs on hardware you control — local or remote — and it keeps sessions, memory, scheduling, and task checkpoints alive across Gateway restarts. The upstream project, kirodotdev/KiroCrew, sits at 4400 stars, is written in Python, and ships under Apache-2.0.

A Chinese translation of that project now exists: KiroCrew-cn. This article is about what the project does, how to get it running, and what the Chinese edition actually adds.

What KiroCrew is

The official one-liner: a persistent workspace for development work that self-improves and continues beyond one session.

That sentence is doing a lot of work, so let me unpack it against what the README actually claims.

• Persistent. Sessions, memory, scheduling, and task checkpoints survive a Gateway restart. Scheduled jobs and unattended multi-step tasks keep running.
• Multi-surface. You interact through a desktop app, a web dashboard, and a CLI. Slack and Discord are message channels for continuing the same work.
• Unattended by design. Multi-step tasks can run without you watching. Periodic jobs fire on your schedule. A heartbeat mechanism monitors the system until something needs attention.
• Extensible through Apps. Kiro Crew Apps tailor the experience to specific work scenarios by combining dedicated interfaces with agents, skills, schedules, integrations, and backend services.

The default agent runs on top of kiro-cli. That is a separate dependency you install and log into yourself. On first startup KiroCrew checks for it, and if it is missing, links you to the official install guide.

Why a Chinese edition matters

The upstream README is long. It has a quick start, a source-build path, a rationale section, a feature list, an architecture explanation, a security section, install notes, telemetry documentation, and a docs index. For a developer whose first language is Chinese, that is a real reading cost before the first command even runs.

The Chinese edition does two things, and the distinction is stated explicitly in the repo:

1. A translated README. The body is a Chinese translation of the original project documentation, with a stated goal of staying faithful to the source. The original English README is kept alongside it as README_en.md.
2. A supplementary quick-start guide (中文快速上手). This part is not a translation. It is an added orientation layer written for Chinese-speaking users, with the explicit purpose of letting you get the project running without reading the whole README first.

That second part is the more interesting one. Translation alone does not lower the barrier much if the original document is structured around assumptions you do not share. A quick-start that front-loads "what problem does this solve," "what is the shortest path to a running instance," and "what will bite you" is a different artifact from a translated reference.

The repo also invites corrections: if something is translated inaccurately, open an Issue or a PR.

The shortest path to a running instance

If you want to skip the source build, the README gives a one-line install for the signed Stable wheel. No repo clone, no frontend build:

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

Then open http://localhost:5476.

To pin an exact release, pass --version:

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

One constraint worth knowing before you try to pin something old: the minimum pinnable version is 0.1.2. Versions 0.1.0 and 0.1.1 predate manifest signing, so there is no signed manifest to resolve against.

Before any of this, install and log into kiro-cli. The README does not provide an explicit command for that step in the quick-start section — it defers to the install guide. This is the single most common first-run failure, because the prerequisite check happens at startup and the default agent will not run without it.

Building from source

The README's source path is short but has one non-obvious step:

git clone <repo>
cd KiroCrew
make build
source .venv/bin/activate
kirocrew setup
kirocrew doctor
kirocrew gateway

The non-obvious part is the frontend. It is built separately with npm/Vite inside the website/ directory, and the output has to be staged into src/kiro_crew/static/dist before packaging. If you build the Python side and wonder why the web dashboard is blank, that is usually why.

kirocrew doctor after setup is worth running rather than skipping. It is the cheap way to find out that kiro-cli is missing or unauthenticated before you spend time debugging a gateway that starts but does nothing useful.

Environment requirements

From the README:

• OS: macOS, Linux, and Windows. Windows goes through a native source install — there is a separate Windows guide.
• Python: 3.12+. pyproject.toml declares requires-python = ">=3.12", and CPython 3.12–3.13 are supported.
• Node.js: 22.12+ for source builds, with 24 LTS recommended, plus npm.
• Default agent dependency: kiro-cli, installed on the Gateway host, with kiro-cli login run once.
• Architectures: macOS on x86_64 and arm64; Linux on x86_64 and aarch64.
• Docker: a public multi-arch image at ghcr.io/kirodotdev/kirocrew:stable.

For users on mainland China networks, the README notes that mirror sources or download acceleration may be needed. It does not provide specific mirror configuration — that is deferred to the install guide.

Install paths beyond the one-liner

The one-line script is not the only option. The README lists:

• Desktop app with auto-update, for macOS (.dmg) and Windows x64 (-Setup.exe). Linux users are pointed at the one-line install as the starting point.
• Linux packages — .deb, .rpm, and AppImage — covered in the install guide alongside Insider and Nightly links, architecture support, platform requirements, and sandbox setup.
• Docker for always-on servers.
• Source build, as above.

There are three release channels. Stable is the default. Insider follows release candidates. Nightly follows main. The release runbook documents the current triggers, version shapes, promotion behavior, cadence, and update-channel semantics.

A gotcha in the installer

The install script only uses precompiled wheels by default. If a dependency has no precompiled wheel available, the script refuses to build it rather than falling back to a source compile. To allow source builds you have to opt in:

KIROCREW_ALLOW_SOURCE_BUILDS=1

That requires a C toolchain and the relevant -dev headers. On a minimal container image, this is the difference between a clean install and a wall of build errors, so it is worth knowing before you hit it.

What the Chinese edition does not do

It does not fork the code. It does not change behavior. It is a documentation layer, and the repo is explicit about which parts are translation and which parts are added orientation. The upstream project is at 4400 stars; the Chinese edition is new and has no star history to speak of yet, so treat it as a translation in progress rather than a community with a track record.

If you are a Chinese-speaking developer who bounced off the upstream README, the value here is concrete: a quick-start that tells you about the kiro-cli prerequisite, the frontend staging step, the 0.1.2 pinning floor, and the KIROCREW_ALLOW_SOURCE_BUILDS flag before you discover them the hard way. That is a few minutes saved per person, multiplied across everyone who tries the project.

If you find a translation error, the repo asks for an Issue or a PR. That is the whole maintenance model.

---

Chinese documentation: https://github.com/yangshun2005/KiroCrew-cn

I'm an independent enterprise AI delivery consultant — private LLM deployment, RAG, agent workflows, AIOps. If your team is stuck somewhere in that stack, my inbox is open.