IDE 0.x reference

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.

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.

In IDE 0.x, hooks were created through a dedicated form UI:

1. Navigate to the Agent Hooks section in the Kiro panel
2. Click the + button to create a new hook
3. 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.

• 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

{
  "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
    }
  ]
}

• 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.

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.

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.

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.

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.

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

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:

{
  "kiroAgent.commandDenylist": [
    "rm -rf",
    "sudo",
    "chmod 777",
    "eval",
    "curl | sh",
    "wget | sh",
    "> /dev/",
    "mkfs",
    "dd if="
  ]
}

1. Denylist check (highest priority) — if command contains a denied pattern, require approval
2. Trust check — if command matches a trusted pattern, auto-approve
3. Default — require manual approval

These settings are replaced by permissions.yaml shell capability rules:

# 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.

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.

• 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.

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.

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.

In IDE 0.x, agent configs were JSON-only and supported the same fields as CLI 2.x.

.kiro/agents/my-agent.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"]
}

• 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.

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.

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.