Cloud sessions

A cloud session runs the Kiro agent harness in a managed cloud sandbox instead of on your machine. The session belongs to your Kiro account, not to any one app: start it in the browser, hand it a long task, close your laptop, and check on it later from your phone, your terminal, or the IDE. The agent keeps working in the sandbox whether or not you're connected.

Cloud sessions are the execution environment behind Kiro Web and Mobile, and the IDE and CLI can create and attach to the same sessions. Because every surface talks to the same harness through the same protocol, a cloud session behaves like any other Kiro session: same steering, same permissions, same tools. The one difference is where the work happens.

When you create a cloud session, Kiro provisions an isolated sandbox and starts the same agent harness that runs locally in the IDE and CLI. If you attach repositories, Kiro clones them server-side through your connected source provider; your local working copy is never uploaded. The agent reads, edits, builds, and runs shell commands inside the sandbox, and delivers results back through your source provider (typically as a pull request) or directly in the conversation.

The session itself lives in a cloud session store, separate from any client:

• Clients attach and detach: the Web app, Mobile app, IDE, and CLI are all views onto the same session. Disconnecting a client doesn't stop the agent, and an in-flight task keeps running.
• State survives your machine: conversation history, bound repositories, and the sandbox's file state persist in the cloud. Reattach from any surface and the transcript replays where you left off.
• Approvals wait for you: if the agent needs permission for an action while nobody is connected, the request waits and is presented to the next client that attaches.

For details on the sandbox itself (network access, environment variables, and environment configuration), see the Sandbox documentation.

• A paid Kiro subscription (Pro or higher)
• A connected GitHub or GitLab account, if you want to work on repositories
• For AWS Identity Center organizations: an administrator must first enable Kiro Web from Settings > Kiro Settings in the AWS account where Kiro is configured. Cloud sessions run in US East (N. Virginia) us-east-1 only during the preview

Cloud sessions draw a clear boundary between your machine and the sandbox:

Configuration follows the same scopes as everywhere else, with one thing to know:

• Project configuration travels with the repo: steering, specs, custom agents, hooks, and MCP servers committed under .kiro/ in your repository apply in cloud sessions automatically, because the sandbox clones the repository.
• Personal configuration stays local: your ~/.kiro/ directory isn't applied automatically. To bring personal steering, custom agents, skills, and hooks into cloud sessions, sync them from Cloud configuration in Kiro Web settings.
• Sandbox environment: internet access, environment variables, and setup commands are covered in the Sandbox documentation.

A cloud session is one session, whichever app you view it through:

• Repository set is fixed: you choose repositories when you create the session (the CLI can also add them later with /repo). To work on different repositories, start a new session.
• No branch selection: you can't choose a branch when attaching a repository. Ask the agent to check out or create a branch once the session is running.
• No Supervised mode: cloud sessions run in Autopilot or Autonomous; per-change approval isn't available.
• No renaming: cloud sessions can't be renamed from the IDE or CLI.
• Surface gaps: each tab above lists commands and affordances that don't work in cloud sessions yet. Expect these to narrow as the preview matures.

• How Kiro works - the Kiro agent harness and where it runs
• Kiro Web - the browser-native cloud session experience
• Sandbox - network access, environment variables, and environment configuration
• Agent Focus Mode - the IDE surface for cloud sessions
• CLI session management - listing, resuming, and deleting sessions
• Configuration scopes - where settings live and how they travel