[Feature] Add Kiro (AWS Agentic IDE) support

[dgallitelli]

Is your feature request related to a problem? Please describe.

CloudUI currently supports Claude Code, Cursor CLI, Codex, and Gemini-CLI as providers. Kiro — AWS's agentic IDE built on Claude — has no support yet, leaving users who work with Kiro unable to manage their sessions through CloudUI.

Describe the solution you'd like

Add Kiro as a supported provider in CloudUI, similar to how Codex and Cursor CLI were integrated.

Kiro is available both as a desktop IDE and a CLI tool:

• CLI install: curl -fsSL https://cli.kiro.dev/install | bash
• Docs: https://kiro.dev/docs/
• Downloads: https://kiro.dev/downloads/

Kiro uses a .kiro/ directory for project-level configuration (agents, skills, hooks, steering files, MCP config), analogous to .claude/ for Claude Code.

Key Kiro concepts relevant to CloudUI integration:

• Specs — structured feature planning documents
• Hooks — automated tasks triggered by file events (.kiro.hook files)
• Steering — persistent rules/context files (.kiro/steering/*.md)
• MCP Servers — same protocol as Claude Code (.kiro/settings/mcp.json)
• Skills — reusable agent task templates

Prior art / related work

Someone has already done exploratory work adapting Claude Code workflows to Kiro's native format:

• PR: affaan-m/everything-claude-code#548 — Add Kiro IDE support (.kiro/) (merged) — demonstrates the dual-format agent structure (JSON for CLI, MD for IDE), hook format, and .kiro/ directory layout
• Source repo: ihimanss/kiro-everything-claude-code

The contribution was reviewed with guidance from an AWS team member (@aws-hsungmin), suggesting some level of official interest.

Additionally, there's an open issue in the awslabs/mcp repo about Kiro CLI/IDE documentation: awslabs/mcp#2680.

Most notably, @4regab already built a standalone mobile bridge for Kiro: kiro-mobile-bridge. It connects to a running Kiro IDE instance via Chrome DevTools Protocol (CDP), scanning ports 9000–9003/9222/9229, and serves a mobile web UI with chat, code viewer, and tasks panel. This validates the demand for a remote UI for Kiro and also gives insight into how Kiro exposes its internals (CDP + port-based discovery), which could inform how CloudUI communicates with it.

Additional context

Kiro is built on Claude under the hood, so it shares much of the same conceptual model as Claude Code. The main integration points for CloudUI would be:

1. Detecting Kiro sessions/projects (.kiro/ directory)
2. Launching and communicating with the kiro CLI process (or via CDP for IDE mode)
3. Displaying Kiro-specific session metadata (specs, hooks, steering)
4. Adding Kiro to the provider selection UI alongside Claude, Cursor, Codex, and Gemini

Given the existing provider architecture in CloudUI and the prior community work on Kiro ↔ Claude Code interoperability, this should be a natural fit.

[dgallitelli]

Implementation Analysis

After studying the CloudUI codebase, here's a detailed breakdown of what adding Kiro support would actually involve.

---

Architecture overview (how other providers are structured)

Each provider in CloudUI has this set of pieces:

Layer	File(s)	Role
CLI spawner	server/<provider>-cli.js	Spawns the process, streams output over WebSocket
Provider adapter	server/providers/<provider>/adapter.js	Normalizes provider-specific messages into NormalizedMessage
Provider registry	server/providers/registry.js	Registers the adapter
Route	server/routes/<provider>.js	Express route for provider-specific endpoints
Session discovery	server/projects.js	Scans disk for existing sessions, attaches to projects
Model constants	shared/modelConstants.js	Available models list for UI
Agent dispatch	server/routes/agent.js	Routes incoming chat messages to the right spawner
Frontend	src/components/..., src/stores/useSessionStore.ts	Provider selector UI, session store

Codex and Gemini were both added following this exact pattern. Kiro would be the 5th provider.

---

Files to create (new)

server/kiro-cli.js — highest complexity; this is the core unknown

Responsible for spawning the kiro CLI process and streaming events back over WebSocket. The equivalent files for reference: gemini-cli.js (~300 lines using child_process.spawn) and openai-codex.js (~250 lines using the Codex SDK).

server/providers/kiro/adapter.js — medium complexity once message format is known

Must implement the ProviderAdapter interface: normalizeMessage(raw, sessionId) and fetchHistory(sessionId, opts). The Codex adapter (server/providers/codex/adapter.js) is ~200 lines and is a clean template.

server/routes/kiro.js — low complexity

Likely just a session-delete endpoint. The Gemini equivalent is ~25 lines.

---

Files to modify (existing)

File	Change	Effort
server/providers/registry.js	Import and register kiroAdapter	~3 lines
server/providers/types.js	Add 'kiro' to SessionProvider typedef	1 line
shared/modelConstants.js	Add KIRO_MODELS constant	~10 lines
server/routes/agent.js	Add Kiro to provider validation + dispatch switch	~20 lines
server/projects.js	Add getKiroSessions() function + wire into project discovery	~100 lines
server/index.js	Mount kiroRouter	~3 lines
Frontend session store	Add kiroSessions field to project shape	~10 lines
Frontend provider selector	Add Kiro card to provider selection UI	~20 lines

---

The two integration paths — and the key unknown

This is where the effort estimate forks significantly:

Path A: Kiro CLI (process spawn — preferred)

Spawn the kiro binary with child_process.spawn, pipe stdin/stdout. This is exactly how Gemini CLI and Cursor CLI are integrated. It would give CloudUI full control over sessions without requiring the IDE to be running.

Blocker: The output format of the kiro CLI is not yet documented publicly. Before implementing kiro-cli.js, someone needs to run kiro interactively and capture:

• What does a session start look like on stdout?
• Is output JSONL? SSE? Streaming JSON?
• How do you resume a session (like gemini --resume <id> or codex.resumeThread(id))?
• Where does Kiro CLI persist sessions on disk (~/.kiro/? .kiro/ in the project)?

Path B: Chrome DevTools Protocol bridge (IDE companion)

@4regab's kiro-mobile-bridge already proved this works: connect to the running Kiro IDE via CDP on ports 9000–9003/9222/9229, scrape the chat + tasks panels via DOM snapshots, inject messages by executing JavaScript in the renderer.

This path does NOT require understanding the CLI format — it works against any running Kiro IDE instance. However, it is inherently fragile (depends on internal DOM structure, breaks on IDE updates) and requires the desktop IDE to already be running, which contradicts CloudUI's headless/remote value proposition.

Recommendation: Attempt Path A first. If the CLI format can be documented (or reverse-engineered by inspecting ~/.kiro/ after a session), this is the correct long-term approach. Path B is a viable stopgap.

---

Session storage — where to look

Kiro's .kiro/ directory in each project stores:

.kiro/
  specs/          ← spec files (requirements, design, tasks)
  hooks/          ← *.kiro.hook files
  steering/       ← *.md files with persistent context
  settings/       ← mcp.json, etc.

For session history (analogous to ~/.claude/projects/ or ~/.codex/sessions/), check ~/.kiro/ in the home directory — this is the most likely location for persisted session JSONL files, but needs confirmation.

---

Effort summary

Component	Effort	Blocked by
Registry, types, models, route	~1 hour	Nothing — do first
Agent dispatch, frontend wiring	~2 hours	Nothing
Session discovery in projects.js	Half a day	Knowing where Kiro stores sessions on disk
providers/kiro/adapter.js	Half a day	Knowing the message format
kiro-cli.js (the hard part)	1–3 days	CLI output format + session resume API

Total estimate: 2–4 days once the CLI format is known. The investigation/reverse-engineering phase is the biggest variable.

---

Suggested first steps for a contributor

1. Install the Kiro CLI (curl -fsSL https://cli.kiro.dev/install | bash) and run a session, capturing raw stdout
2. Check what ~/.kiro/ contains after a session (session files, format)
3. Document findings here — that unblocks the rest of the implementation
4. Follow the Codex adapter + gemini-cli.js patterns for implementation