What's actually in Kiro IDE 1.0
Kiro IDE 1.0 brings better permissions, new agent modes, improved chat interface, plan mode, improved hooks, and easier session management. This quick overview covers the latest changes
In this article
The old trust model was too narrow
In 0.x, the central control was
kiroAgent.trustedCommands in settings.json . You could trust certain shell commands or accept prompts as they appeared. That helped with terminal friction, but it was not a complete security model for an agent that can read files, edit code, call MCP servers, search the web, and delegate work.Kiro 1.0 replaces that with a single, capability-based permission system defined in
permissions.yaml . You can create rules for file access, shell commands, MCP tools, web requests, and subagents, and use glob patterns to limit them to specific files or commands.When multiple rules apply, Kiro resolves them by restrictiveness: a
deny rule overrides ask , and ask overrides allow . A more permissive rule cannot override a stricter one.On a fresh 1.0 installation, the agent can read workspace files and run read-only Git commands. Writes, shell commands, and MCP calls ask first. If a decision is routine, save it as an always-allow or always-deny rule for either the current workspace or every workspace.
That sounds like configuration detail, but it changes the default posture. Permissions are no longer an escape hatch for terminal prompts. They are the contract between an agent and a repository.
Trust-all tools aka YOLO Mode
If you are used to a CLI flag that trusts all tools, the equivalent is a permissive permissions file you may edit the permissions.yaml file. A global file lives at
~/.kiro/settings/permissions.yaml ; workspace-scoped permissions live under ~/.kiro/workspace-roots/<hash>/permissions.yaml .rules:
- capability: all
effect: allowWith that rule, Kiro does not pause for consent before reading, writing, running commands, or calling MCP tools. It is useful in a disposable environment or for a developer who wants uninterrupted automation and understands the trade-off. Use this at your own risk.
A more practical configuration keeps the broad allow rule but asks before commands with an outsized blast radius:
rules:
- capability: all
effect: allow
- capability: shell
effect: ask
match:
- "rm *"
- "rm -rf *"
- "rmdir *"
- "del *"
- "Remove-Item *"
- "git push*"
- "git reset*"
- "git clean*"Because
ask takes precedence over allow , this lets routine work proceed while pausing at commands that can delete work, publish a package, rewrite history, or affect a remote repository.There is one important limitation. These rules only match shell commands. Kiro's built-in Delete File tool operates under the
fs_write capability, and there is no separate fs_delete capability. Allowing all capabilities can therefore allow a deletion through the file tool without a shell prompt. Protecting that path means protecting file writes as a whole.Kiro also protects its own permission configuration locations. The agent cannot rewrite the settings and workspace-root permission files that define its authority.
Agents become portable configuration
In 1.0, an agent profile can describe its operating boundary as well as its role. Tags such as
read , write , shell , and web replace long lists of individual tools. An agent can carry MCP server configuration and permission rules inline. Put the profile under version control and the behavior travels with the repository instead of living only in an IDE preference.You can switch agents from the chat input without losing the current conversation. The built-in agents are Default, Spec, Quick Spec, Bug Fix, and Plan.
Chat is now part of the workspace
For a long time, agent chat in an IDE meant a narrow side panel beside the code. It worked until the conversation itself became an artifact worth reviewing: a large diff, a multi-step plan, a debugging trail, or an implementation discussion that needs more room than a sidebar can give it.
In 1.0, right-click a session tab and choose Open in Editor. The conversation becomes a full-width editor tab that can be split next to source files, moved between editor groups, or placed on another monitor. The panel and the editor tab are views of the same session, so messages sent from either one stay in sync.
You can also export a session as a portable, read-only ZIP. It contains
chat.md with the conversation and metadata.json with session metadata, which makes a review, archive, or handoff less dependent on keeping the original IDE session open.Agent Focus puts the work around the conversation
Dockable chat makes a single conversation easier to work with. Agent Focus changes the whole layout around that premise.
It is an experimental, agent-first workspace with sessions on the left, the active conversation in the main panel, and specs, diffs, and related context on the right. You can run multiple independent sessions in parallel and start each one with a workflow: Spec, Plan, Bug Fix, Quick Spec, or freeform.
Both Autopilot and Supervised modes work in Agent Focus. The standard editor has not disappeared, either. Use the top-right toggle to return to Editor View when you want the terminal, Git tooling, direct file editing, Powers, or MCP configuration in their familiar place.
The distinction is useful: Agent Focus is for steering and reviewing agent work; Editor View remains the place for the rest of the development environment.
Plan mode separates thinking from editing
The new Plan agent is intentionally read-only. It can inspect a codebase and research relevant material, but it cannot change files or run commands. Its job is to make the implementation decision explicit before an execution agent starts making edits. Plan is also available as a starting workflow in Agent Focus, alongside Spec, Quick Spec, and Bug Fix.
A typical planning pass starts with structured, multiple-choice questions. Plan then explores the relevant code paths, identifies the affected pieces, and produces a task breakdown with objectives, implementation guidance, and ways to demonstrate each task. Review or revise the plan, then approve the handoff. The approved context moves back to an execution agent.
Hooks have a real data model now
Hooks are where a convenient automation feature becomes part of a team's development workflow. In 0.x, they used a
.hook format and supported file, session, and tool triggers, along with manual hooks.Version 1.0 moves hooks to structured JSON in
.kiro/hooks/*.json . The existing trigger types remain, and PreTaskExec and PostTaskExec add a way to run automation around spec-task execution.The Agent Hooks panel can ask Kiro to create a hook from a natural-language description. If you prefer something user-invoked rather than event-driven, create a manual steering file in
.kiro/steering/ ; it becomes available as a /<filename> slash command.Migrating existing hooks
Legacy hooks do not run until they are migrated. In the Agent Hooks panel, each unmigrated hook shows an upgrade badge. Click it to convert the hook, and the migrated version becomes active immediately. You can also open the Command Palette with
Ctrl+Shift+P and search for Migrate Hook.The old file stays on disk, but Kiro stops loading it. Manual hooks from 0.x migrate to manual steering files instead of becoming v1 event hooks.
Existing sessions need one small migration
IDE 1.0 uses a new session storage format. Sessions created in 0.x do not appear in the session list until they are migrated.
There are two paths: click Migrate beside an unmigrated session, or open it and let Kiro migrate it automatically. There is no deadline. Unmigrated sessions remain stored locally until you need them.
If a migration produces an incomplete result, right-click the session and use Force Re-migrate to start again, or choose Show Migration Logs to inspect what happened.
What to do after upgrading
The highest-value first step is not turning every permission on. Open your permissions configuration, decide what should be trusted in the current workspace, and let the initial prompts reveal where the real friction is.
Then migrate the hooks and sessions you still use. Try Open in Editor on a long-running conversation. If your next change is broad enough to need a design decision, start it in Plan mode instead of making an execution agent infer the design while it edits.
Kiro 1.0 is not simply an IDE with more agent controls. It is an attempt to make agent behavior reviewable, configurable, and repeatable. The features make the most sense when used together: permissions define the boundary, agent profiles package a role, hooks encode local workflow, and the workspace gives the resulting conversation enough room to be part of the engineering record.
Download the release from kiro.dev/downloads . Auto-updates are paused, so use the manual download for version 1.x or later.
#kiro #agents #aiengineering #agenticcoding
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article