Kiro Crew 0.7.0 keeps accepted work through Gateway restarts and widens pull-request watches

Kiro's Crew changelog for version 0.7.0, dated September 24, 2026, describes a release aimed at making background work more durable. It is the only source for this story: the details below come from Kiro's own release notes, and we found no independent coverage.

The central change is a queue. Kiro says accepted subagent work, Task Runner steps and workflow calls now enter a durable queue before they run, and that a Gateway restart restores queued work instead of dropping it. The System page shows the active queue and the concurrency capacity in force. Kiro also says the Gateway checks for updates at startup and every twelve hours, and that an automatic update pauses new work and waits for active turns, scheduled runs, subagents, Task Runner steps and workflows to go idle before restarting.

The second change is reach. According to Kiro, the structured pull-request watch now accepts GitHub, GitLab, Bitbucket Cloud and Azure DevOps Services URLs. Azure DevOps Server and Bitbucket Data Center are not supported, and Azure DevOps and private Bitbucket watches must start from a dashboard conversation. The company lists the command-line tools and credentials each service needs, such as glab for GitLab and az for Azure DevOps.

Kiro also describes an optional Crew log that records an append-only session trail and a durable session ledger across context compaction. It is enabled by setting KIROCREW_CREW_LOG=1 in a Crew environment file and restarting the Gateway. Most settings, the company says, now apply as soon as they are saved, with the Slack slash-command field the current exception that needs a restart.

Other items include a turn minimap and combined model and reasoning controls in desktop chat, isolated pods on Windows, and, in Preview, OpenCode and goose agent backends, per-turn model routing by a component called Jev, and remote crews on AWS Fargate.

What is confirmed and what is not: these are the vendor's descriptions of its own software. We have not tested the release, and no second source verifies how the restart recovery or the new watches behave in practice. The changelog also lists later 0.7.1 and 0.7.2 patches, so the 0.7.0 behavior may have changed since.

Why it matters: for teams using agents that run long tasks, losing queued work on a restart is a practical failure mode, and watching pull requests outside GitHub removes a common limit. Whether the queue holds up under real workloads remains for users to show.

Revised 16 October 2026: Guth re-read the original sources and rewrote this article. The earlier version remains available as revision 1.