0.x reference - IDE 1.x - Docs - Kiro Loading image... Product * About Kiro * IDE * CLI * Web * Mobile * Crew * Pricing * Downloads For * Enterprise * Startups * Students Community * Overview * Ambassadors * Discord * Events * Powers * Shop * Showcase Resources * Docs * Blog * Changelog * FAQs * Report a bug * Suggest an idea * Billing support Social * * * * * * * English Site Terms License Responsible AI Policy Legal Privacy Policy Cookie Preferences English Loading image... * Apps * CLI * Web * Enterprise * Pricing * Docs * Community * Resources SIGN IN DOWNLOADS Loading image... Get Started Installation Authentication Your first project Models Overview Available models Reasoning effort Features How Kiro works Specs Steering Hooks MCP Permissions Custom agents Agent Skills Powers Cloud sessions Compaction Kiroignore Checkpoints and rewind Built-in tools Configuration scopes IDE 1.x What's new in 1.0 Setup & First Run Editor Chat Experimental Troubleshooting 0.x reference CLI What's new in 3.0 Setup & First Run Terminal UI Chat Voice mode Headless mode ACP Auto complete Experimental 2.x reference Crew Quick start Installation Running 24/7 Chat Agent Capabilities Features Interfaces Apps System & storage Configuration Security Troubleshooting Web Setup & First Run Identity Center Connect your repositories Working with the agent Autonomous mode Automations Memory Configuration Sync Sandbox Mobile - Preview Overview Commands and Reference CLI commands Slash commands Built-in tools Exit codes Settings Billing Overview Managing your subscription Upgrading your plan Downgrading your plan Cancelling your plan Purchasing add-on credits Managing your payments Managing usage notifications Managing your taxes Contacting billing support Deleting your account Related questions Enterprise Concepts Onboarding quickstart Connecting your identity provider Deployment options Subscribe your team Manage subscriptions Governance Monitor and track Settings Managed updates Billing IAM Supported regions Privacy and Security Overview Data protection Code references Compliance validation Infrastructure security IAM permissions Firewalls, proxies, and data perimeters VPC endpoints (AWS PrivateLink) Guides Overview Language support Learn by playing Migration Migrating from Q Developer Migrating from VSCode Upgrading from Q CLI * Docs * * IDE 1.x * * 0.x reference Copy page View as Markdown IDE 0.x reference Copy page View as Markdown This page documents IDE 0.x behavior for users who haven't yet migrated to 1.0. For the current format, see the Features documentation. Hooks In IDE 0.x, hooks were stored in .kiro.hook files. In IDE 1.0, hooks moved to .kiro/hooks/*.json files using a versioned JSON schema. Hook creation UI (removed in 1.0) In IDE 0.x, hooks were created through a dedicated form UI: * Navigate to the Agent Hooks section in the Kiro panel * Click the + button to create a new hook * Choose how you want to create the hook: * Manually create a hook — opens a form with fields for Title, Description, Event, Tool name, File pattern, Action type, and Instructions/Command * Ask Kiro to create a hook — describe a hook using natural language, review the generated configuration, and click Save Hook The form fields were: * Title — a short name for the hook * Description — what the hook does * Event — the trigger type (e.g., File Save, Post Tool Use, Pre Task Execution) * Tool name — for Pre/Post Tool Use hooks, specify which tools to match * File pattern — for file event hooks, specify which files to match * Action — choose Ask Kiro (agent prompt) or Run Command (shell command) * Instructions or Command — the prompt or shell command to execute You could also open the Hook UI from the Command Palette with Cmd + Shift + P (Mac) or Ctrl + Shift + P (Windows/Linux) and typing Kiro: Open Kiro Hook UI . In IDE 1.0, this form was replaced by a conversational flow — clicking + now pre-fills a prompt in chat and you work with the agent to configure the hook. Legacy manual Hooks in 1.0 Existing IDE 0.x Hooks with the userTriggered event continue to appear in the Agent Hooks panel with a legacy label. Enabled legacy manual Hooks remain runnable from the panel using the play button. You can't create a new userTriggered Hook in IDE 1.0. For a new on-demand workflow, choose Manually create a steering file . The resulting file uses inclusion: manual and runs as a /<filename> slash command. See Steering . What changed in 1.0 * Hook files moved from .kiro.hook to .kiro/hooks/*.json * New version: "v1" JSON schema with structured when / then fields * Trigger names and behavior remain the same * New fields: name , description , enabled , timeout Current format (1.0) json { "version" : "v1" , "hooks" : [ { "name" : "format-on-save" , "description" : "Run Prettier on saved TypeScript files" , "enabled" : true , "when" : { "type" : "fileEdited" , "patterns" : [ "\\.ts$" ] } , "then" : { "type" : "command" , "command" : "prettier --write {{filePath}}" } , "timeout" : 10 } ] } Available triggers (unchanged from 0.x) when.type value Fires when when.patterns matches sessionStart Session begins Not evaluated agentStop Agent stops Not evaluated promptSubmit User sends a message Not evaluated preToolUse Before a tool executes Tool name postToolUse After a tool executes Tool name fileCreated A new file is created File path fileEdited A file is saved/modified File path fileDeleted A file is deleted File path preTaskExecution Before a spec task starts Not evaluated postTaskExecution After a spec task finishes Not evaluated userTriggered Triggered manually by user Not evaluated Action types (unchanged from 0.x) * command — Runs a shell command, receives JSON context on stdin * agent — Injects a prompt into the agent's context at trigger time For the full migration details, see What's new in IDE 1.0 — Hooks . Permissions (Autopilot / Supervised toggle) In IDE 0.x, the Autopilot/Supervised toggle was the only mechanism for controlling agent behavior. In 1.0, a capability-based permissions.yaml layer was added beneath it for fine-grained control. How it worked in 0.x The IDE had two modes accessed via Settings → Agent → Agent Autonomy : * Autopilot — the agent proceeded with all operations without prompting * Supervised — the agent prompted before every action There was no way to allow some operations while blocking others — it was all-or-nothing. What changed in 1.0 The Autopilot/Supervised toggle still exists and works as before. What's new is a permissions.yaml layer that applies after the autonomy mode: * Autopilot + permissions — the agent proceeds autonomously, but permissions.yaml rules can still deny or ask for specific capabilities * Supervised + permissions — the agent prompts for everything as before, but allow rules in permissions.yaml can pre-approve trusted operations so they don't prompt This means you can use Autopilot mode without giving the agent unrestricted access — deny dangerous operations while allowing routine ones to proceed silently. For the full permissions reference, see Permissions . For migration details, see What's new in IDE 1.0 — Permissions . Terminal trusted commands and denylist In IDE 0.x, terminal command approval was controlled through two settings: Trusted Commands and Command Denylist . In 1.0, this is replaced by permissions.yaml shell capability rules. Trusted commands ( kiroAgent.trustedCommands ) Configured in Settings → Kiro Agent: Trusted Commands at user or workspace level. Used prefix matching with * wildcards: * ["npm install"] — exact match only * ["npm install *"] — partial wildcard (npm install with any args) * ["npm *", "git *"] — full wildcard (any npm/git command) * ["*"] — universal trust (all commands auto-approved) Matching rules: * Prefix-based string matching * * matches any characters after the prefix * Chained commands ( && , | ) were trusted if the first command matched Command denylist ( kiroAgent.commandDenylist ) Configured in Settings → Kiro Agent: Command Denylist . Used substring matching — if any denied pattern appeared anywhere in the command, approval was required regardless of trust settings. Recommended denylist patterns: json { "kiroAgent.commandDenylist" : [ "rm -rf" , "sudo" , "chmod 777" , "eval" , "curl | sh" , "wget | sh" , "> /dev/" , "mkfs" , "dd if=" ] } Evaluation order * Denylist check (highest priority) — if command contains a denied pattern, require approval * Trust check — if command matches a trusted pattern, auto-approve * Default — require manual approval What changed in 1.0 These settings are replaced by permissions.yaml shell capability rules: yaml # Equivalent of trustedCommands: ["npm *", "git *"] rules : - capability : shell match : [ "npm *" , "git *" ] effect : allow # Equivalent of commandDenylist: ["rm -rf", "sudo"] - capability : shell match : [ "rm -rf *" , "sudo *" ] effect : deny Key differences: * Glob patterns instead of prefix/substring matching * Deny-always-wins across all scopes (not just a pre-check) * Configurable per workspace and user scope in YAML files * Settings UI ( kiroAgent.trustedCommands , kiroAgent.commandDenylist ) no longer used For the full permissions reference, see Permissions . Summarization (replaced by compaction in 1.0) In IDE 0.x, when the context window reached 80% of the model's limit, Kiro would summarize all messages in the conversation to bring the context length back below the limit. A context usage meter in the chat panel showed the current percentage. What changed in 1.0 * Renamed from "Summarization" to "Compaction" * Auto-compaction now happens in the same session (no new session created) * Uses structured checkpoint-based summaries (tasks, files, decisions, next steps) rather than a flat summarization * The agent continues in the same chat window after compaction, maintaining continuity * Manual trigger via /compact command For the current behavior, see Compaction . Diagnostics tool (removed in 1.0) In 0.x, the agent had a standalone diagnostics tool that read real-time error detection, syntax validation, and lint findings from your installed language extensions during execution. Installing language extensions and opening a file activated it automatically. What changed in 1.0 The standalone tool was removed. The agent still works with your code's language awareness through the built-in code analysis tools ( read_code , semantic rename), and you can share language-server findings with the agent explicitly using the #Problems context key in chat. On the CLI, the code tool provides LSP-backed diagnostics alongside its other operations. Custom agent config In IDE 0.x, agent configs were JSON-only and supported the same fields as CLI 2.x. Format .kiro/agents/my-agent.json : json { "name" : "my-agent" , "description" : "A development agent" , "prompt" : "You are a senior developer" , "model" : "claude-sonnet-4" , "tools" : [ "fs_read" , "fs_write" , "execute_bash" ] , "resources" : [ "file://AGENTS.md" ] } What changed in 1.0 * Markdown format added ( .md files with YAML frontmatter + body as system prompt) * New fields : excludedTools , includeMcpJson , includePowers , resources (with skill:// URIs), permissions , welcomeMessage * Tags system — tool names simplified to short categories ( read , write , shell , web , @mcp , @builtin , * ) * Agent profiles are backward-compatible — existing JSON configs continue to work without modification * hooks field is CLI-only; IDE ignores it For the current format reference, see Custom agents . Vibe and Spec session types In IDE 0.x, you chose between two session types when starting a new chat: * Vibe mode — free-form conversational coding. The agent worked without structure, handling questions, edits, and exploratory tasks. * Spec mode — structured development. The agent guided you through requirements, design, and tasks phases with approval gates between each phase. You selected the mode via a mode picker when launching a new session. What changed in 1.0 The Vibe/Spec mode picker was removed. Instead: * Default agent — all sessions start with a general-purpose conversational agent (equivalent to Vibe mode) * Workflow selector — when opening a new session, the "Let's build" screen offers built-in workflows (Spec, Plan, Bug Fix, Quick Spec). Selecting one switches the active agent for that session. * Mid-session switching — switch agents at any time via the agent picker in the chat input bar. No need to decide upfront. * Custom agents — create specialized agents for different workflows instead of switching modes This means you no longer need to decide upfront whether a session will be "vibe" or "spec" — you can start conversationally and invoke structured workflows whenever needed within the same session. For the current approach, see Starting a session , Built-in agents , and Specs . Page updated: August 21, 2026 Troubleshooting CLI