Kiro CLI V3 is rolling out as the default experience

By
PO

Pooja Giri

Engineering

JA

Jay Raval

Customer Success

Terminal — 80×24

Loading cast file...

Kiro CLI V3 brings the same agent harness that powers Kiro IDE and Kiro Web to your terminal. With V3, you can give Kiro a task that needs planning, implementation, and review, and keep working while workflow agents handle the steps in the background. You can also start a cloud session and close your laptop without stopping the work. With the new spec mode, you can review requirements and design with Kiro before it starts writing code. And the new tangent mode lets you branch off into parallel conversations without impacting your main session context.

We introduced V3 as an opt-in experience in June and have continued adding new capabilities since then. Our opt-in customers have been enjoying the new features, and we are now preparing to make V3 the default for everyone. Starting October 12, we are gradually rolling out a startup prompt inviting you to switch ahead of the CLI 3.0 release by the end of October. You may not see the prompt right away, but you can try V3 anytime with kiro-cli --v3. This rollout applies only to Kiro CLI.

For most users, the switch won’t require configuration changes. If you have customized your agents, permissions, or integrations, the sections below explain what Kiro migrates automatically and what needs your attention. With CLI 3.0, we are retiring inline shell autocomplete and the CLI desktop app. We are also retiring Classic experience and focusing new capabilities on the terminal UI.

What you can do with V3

We continue to add new features to V3. A few highlights from our latest releases include the following.

You can now keep your work running after you close your laptop, without finding creative ways to keep your laptop “alive”. Start a cloud session with kiro-cli --cloud, attach a repository, and let Kiro work in a managed cloud sandbox. Your agent keeps working when you disconnect, and you can resume the session from another machine. If your organization uses IAM Identity Center, an administrator needs to enable cloud sessions first. Note that cloud sessions only run in US East (N. Virginia) us-east-1 today.

The new memory management lets Kiro learn context across chat sessions. Kiro can learn useful context from your work in local V3 sessions, such as your repository’s commands and conventions, and recall it in later sessions without you having to explain it again. Use /memories to manage what Kiro remembers.

You now get the IDE’s spec mode in the CLI. This lets you review the approach before implementation. You can work through requirements and design with Kiro before it starts writing code. You can also leave inline comments on the document and choose which tasks to run, all from your terminal. Start with /spec new.

We brought back an improved version of /tangent, which we first introduced as an experimental feature in CLI V1. It lets you explore a side thread without impacting your main session context. Tangent was one of our most-requested features, and we are happy to reintroduce it in V3.

As the number of sessions grew, finding the one you needed became harder, like finding a needle in a haystack. We added a new /sessions pane that lets you browse, bookmark, rename, and do much more for easier session management.

You can hand off complex, multi-step work to workflows locally and in the cloud. Give Kiro a task, and workflows coordinate agents to plan, implement, and review it. Each step runs in its own session with fresh context, so a reviewer doesn’t inherit the coding agent’s reasoning. You can keep working in the main chat while the workflow runs in the background, and steer or pause it when needed. Workflows are opt-in, enable them in settings before your first run.

We also made it easier to reuse your setup. Global hooks let you use the same automation across workspaces. Additionally, you can now place AGENTS.md files in subdirectories, not just the repository root, to give Kiro instructions for different parts of your project. For example, you can put frontend conventions in one directory and backend testing instructions in another.

One harness across Kiro

Kiro CLI V3 brings the same agent harness that powers Kiro IDE and Kiro Web to your terminal. The harness owns tools, context, permissions, and model interactions, while each client keeps its own interface.

For our users, that means we can bring a capability built in the harness to the terminal alongside the other clients, rather than porting it later. Our recent workflows launch is an example, we released it across all clients together. The shared harness also gives clients a common configuration and permissions model, so you can reuse your repository’s .kiro/ configuration across clients. What each client supports still differs, and the V3 documentation lists current CLI support.

Loading diagram...

Read more about why we built one agent harness.

What early access taught us

V3 has been available as an opt-in since June. Early-access feedback reinforced that switching agent harnesses shouldn’t mean rebuilding your setup. Your agents, permissions, and familiar workflows need to come with you. That shaped the migration experience.

We defined a “universal config” format that preserves your existing V2 settings and adds the configuration V3 needs. Our migration tooling updates your custom agents to this format, backs up the original configurations, converts supported settings automatically, and flags anything that needs your attention.

How the switch works

During the V3 rollout, Kiro CLI shows a prompt at startup inviting you to switch. It offers three choices:

Loading image...Terminal screenshot of the Kiro CLI startup prompt. A message reads "You're using Kiro CLI V2. Switch to V3 today." and "V3 adds workflows, cloud sessions, and specs. To try it in a new session, run kiro-cli --v3. Learn more: https://kiro.dev/docs/cli/v3/". Below it is a three-option menu: "Switch to V3 and upgrade my configs" (highlighted in purple and currently selected), "Remind me later", and "Don't ask again".
  • Switch to V3 and upgrade my configs: Saves V3 as your default harness, enables automatic agent upgrades, and starts migrating your workspace and global custom agent configurations.
  • Remind me later: Defers the switch and lets the prompt return later.
  • Don’t ask again: Stops showing the prompt. It will not keep you on V2 and your setup will still be upgraded to V3 when CLI 3.0 is released at end of October.

If you wish to switch now, you don’t have to wait for the prompt. Run kiro-cli --v3 to try V3 in a new session. To save it as your default, run:

Loading code example...

If you already use V3, you can drop the --v3 flag once it becomes the default with the CLI 3.0 rollout at the end of October.

If you need to switch back to V2, run kiro-cli --v2. The flag applies to that launch only. You can resume your V2 sessions in V3, but you cannot resume sessions created in V3 in V2.

Before you switch

For most users, the switch won’t require configuration changes. If you have customized your setup, here’s what carries over automatically and what needs a review. The sections below also cover autocomplete and Classic retirement, and changes for ACP integrations.

Custom agents

When you accept the migration prompt, Kiro backs up each original configuration as <name>.json.bak, preserves your existing V2 settings, and adds the configuration needed for V3. Your prompts, model selections, resources, and MCP server definitions carry over unchanged.

Migration also converts supported hooks. Hooks that cannot be converted are left out of the V3 configuration and reported as warnings. Review those warnings and update the affected hooks manually. Your original configuration remains available in the backup. To run or repeat the migration yourself, use /upgrade-agent.

If your team keeps agents in a central repository, you can upgrade the whole directory at once with kiro-cli agent upgrade <dir> in v2.29 and later. Run it with --dry-run first to preview the changes and warnings. It rewrites only agents still in the V2 format and leaves agents that already have a V3 section unchanged.

Custom permissions

V2 uses trusted-tool lists and per-tool settings. V3 uses rules for actions and resources, such as a shell command or file path. When rules overlap, deny takes precedence over ask, and ask over allow, regardless of scope.

Migration converts supported settings, but some patterns need review or manual replacement. After migration, run /upgrade-agent diagnostics and address any conversion warnings before relying on the migrated rules.

--trust-all-tools remains supported in V3. The permissions migration guide explains how individual settings map to the new model.

Agents using use_aws

V3 does not have the use_aws tool. AWS CLI commands run through the shell tool and follow shell approval rules instead.

Recreate your use_aws allow and deny settings as shell permission rules. For commands you want to approve persistently, you can also choose “Always allow” when prompted. Keep rules specific rather than allowing broad patterns such as aws *. For migration guidance, refer to the permissions guide.

Autocomplete

Inline shell autocomplete and the CLI desktop app are being retired and will no longer be available with the CLI 3.0 rollout.

Classic

Classic is not supported in V3 and is being retired gradually. We build new capabilities in the terminal UI.

To switch to the TUI, remove --classic from your aliases or shortcuts and start kiro-cli.

ACP clients

Agent configuration migration does not update your ACP integration. Follow the ACP migration guide for the client changes, and use kiro-cli acp --agent-engine=v3 to start the V3 ACP server.

Regular CLI terminal users can skip this step.

Try V3 today

As we gradually roll out the startup prompt inviting you to switch to V3, we recommend accepting the switch, exploring the new features, and addressing anything in your setup that needs attention before the CLI 3.0 release at the end of October.

Run V3 on your next task. Hand off a task to a workflow, review a spec, or let a cloud session keep working while you step away. The V3 documentation covers setup and current support. Tell us what worked and what blocked you through /feedback or on Discord, and follow the CLI changelog as the rollout progresses.