Cloud Sessions

A cloud session runs the Kiro agent in a managed sandbox on AWS instead of on your laptop. You start it, close the lid, and the agent keeps working; later you attach again from a different machine and pick up exactly where the transcript left off.

What is a cloud session?

The shift is about ownership. A local session belongs to the process running it, so quitting the app ends the work. A cloud session belongs to your account. The surfaces become windows onto the same running thing rather than four separate places to work.

That is also why the four surfaces converged on it. Cloud sessions were always the engine behind Kiro Web and the iOS app, which have no local machine to run on. In August 2026 the desktop tools learned to create and attach to them too: the CLI in v2.17.0 and the IDE in v1.0.293.

Why it exists

Three problems, one answer.

Long runs. An agent working through a large spec can run for a long time, and tying that to a laptop lid is a poor arrangement. Machine independence. Starting something on a work machine and checking it from a phone requires the session to live somewhere neither of them owns. Environments you do not want locally. A sandbox that can install what it likes and run what it likes, without that happening in your home directory, is a genuinely different safety posture.

How it works

Starting one from the CLI. kiro-cli --cloud (or kiro-cli chat --cloud) runs the agent in the managed sandbox. Attach a repository with --repo or the /repo picker. To come back to it later from any machine, --resume-id <id>. Sessions are listed in the CLI’s session dashboard, added in v2.21.0, which shows local and cloud sessions together.

Starting one from the IDE. Cloud Sessions appear inside Agent Focus Mode, the chat-first view introduced with IDE 1.0, as a preview from v1.0.293 onward.

What travels. Project configuration travels with the repository. Your .kiro/steering/ files, your specs, and your hooks are all there because they are committed. Personal settings in ~/.kiro/ stay on your machine unless you sync them through Kiro Web settings. Since September 1, 2026 there is also a route in the other direction: cloud configuration sync pushes agents, MCP servers, powers, steering, skills, and hooks defined in the cloud down to local IDE and CLI sessions, where they appear as read-only previews and remain editable in Web.

Documented limits. Worth reading before you plan around the feature, and worth re-reading later because it is still moving:

Limit	Detail
Plan	A paid plan, Pro or higher
Region	US East (N. Virginia)
Concurrency	At most 10 sessions at once
Repository	Fixed when the session is created; no branch picker
Autonomy	Supervised mode is unavailable
Naming	Sessions cannot be renamed
Local affordances	File opening, checkpoints, and context pickers do not apply
Minimum versions	CLI v2.17.0 or IDE v1.0.293

Enterprises add their own gate. Organizations on AWS Identity Center, Okta, or Microsoft Entra ID need an administrator to enable cloud sessions, and CLI cloud sessions ship opt-in for enterprise administrators since v2.18.0. A working personal setup proves nothing about your work account.

Common mistakes

Treating “I closed the laptop” as “I finished the task.” The agent keeps going and the credits keep being spent. The fix: end runs deliberately, and give unattended work a narrow prompt and a clear stopping point.

Expecting local features to be there. Checkpoints, file opening, and context pickers assume local files. The fix: lean on the repository instead. Commit before you start, and review the result as a diff.

Planning a branch-based workflow. The repository is fixed at creation and there is no branch picker in a cloud session. The fix: create the session against the repository you mean, and use Kiro Web, which gained branch selection on August 31, 2026, when the branch matters.

Assuming Supervised mode is available. It is not. The fix: if a change needs hunk-by-hunk approval, do it locally.

Permissions and safety

A sandbox is not a permission model. The agent in a cloud session is still governed by your permission rules, and a repository is still content the agent will read and act on. Kiro’s own documentation about scheduled cloud work is blunt about the risk: only select repositories you trust, because the agent follows instructions found in repository code.

Where it fits

Cloud sessions answer whose machine runs it. Everything else about Kiro is unchanged: specs, steering, and hooks come from the repository, and the agent loop is the same one every surface runs.

The neighbouring ideas are worth separating. Kiro Web is a surface that uses cloud sessions and adds Automations, autonomous mode, and PR review. Kiro Crew is the opposite arrangement: a persistent agent that runs on your hardware, locally or on a host you control. And the CLI’s headless mode is a third thing again, a one-shot non-interactive run for CI rather than a durable session.

Learn more

• Start a cloud session from the CLI is the fastest way to try one.
• Kiro Web covers the browser surface built on cloud sessions.
• Schedule a Web automation is the recurring version.
• Credits & Pricing explains the shared credit pool.
• Troubleshooting has the “I can’t start a cloud session” checklist.