[mvanhorn]

Summary

Adds a Kiro CLI adapter to agent-manager so AI DevKit can detect, list, start, and route messages to Kiro CLI sessions, the same way it already does for Claude Code, Codex, Copilot, Gemini CLI, OpenCode, and Pi.

Why this matters

Closes the maintainer-declared work item in #109 ("Support Kiro CLI in agent-manager"). Kiro was the one requested coding agent not yet wired into the adapter layer, so agent list, agent start --type kiro, agent sessions --type kiro, and the channel bridge had no way to reach it.

Changes

• New KiroAdapter (packages/agent-manager/src/adapters/KiroAdapter.ts), mirroring the existing PiAdapter: process detection, PID-to-session tracker matching, defensive JSONL session parsing, conversation/listSessions support, and idle/waiting status. Reads sessions from ~/.kiro/cli/sessions and gracefully returns empty results when that directory is absent.
• Extended the AgentType union with 'kiro' and exported KiroAdapter from adapters/index.ts and agent-manager/src/index.ts.
• Registered kiro in the AGENTS registry (launch command kiro-cli; process matcher accepts the kiro-cli or kiro basename) and added it to StartableAgentType.
• Registered new KiroAdapter() in both AgentManager factories (cli/src/commands/agent.ts and cli/src/services/channel/channel-runner.ts), added the Kiro display label, extended the --type help text, and added 'kiro' to VALID_AGENT_TYPES.
• Updated the README agent-support table to list Kiro CLI.

Testing

• New KiroAdapter.test.ts (type identity, kiro-cli/kiro process matching with no false positives, session detection) — agent-manager suite: 435 passed.
• Updated sessions.test.ts, agent.test.ts, channel.test.ts, and StartAgentPane.test.ts for the new type/registration/cycle order — cli suite: 808 passed.
• nx run-many -t build -p agent-manager (swc + tsc typecheck) and nx run-many -t lint -p agent-manager cli both clean.

Fixes #109

AI was used for assistance.

[codeaholicguy]

Hi, thank you for your contribution, but this PR doesn't seem to resolve the integration. I'm not sure that it was tested or not. There is no such ~/.kiro/cli/sessions when Kiro is running.

There are things that can give you hints to solve the integration:

• All Kiro sessions are stored under ~/.kiro/sessions/cli/
• When a session is running, there will be a lock file in the session folder such as `~/.kiro/sessions/cli/.lock; this file will contain PID info; we can use this to map with process. If the session is ended, the lock file will gone.
• ~/.kiro/sessions/cli/<session-id>.json contains all metadata of the session, such as cwd, etc
• ~/.kiro/sessions/cli/<session-id>.jsonl contains the conversation history, including user message, assistant message, tool use, etc

Please make sure you test all the workflows, from agent list, agent send, agent open, and all the features work well with the new agent type (kiro) in the agent console.

Thank you.

[mvanhorn]

You were right, it was not tested against a running Kiro and the path was wrong.

Now reads ~/.kiro/sessions/cli/, discovers running sessions from the lock file in that directory, and resolves each lock to its sibling metadata and transcript, rather than scanning ~/.kiro/cli/sessions which never exists.

431 tests pass in agent-manager, typecheck and lint clean. I still have not been able to run it against a live Kiro session, so if you can spot-check the lock and transcript shapes against a real one that would help.

[mvanhorn]

@codeaholicguy thanks for the pointers, they were exactly what was needed. Pushed in 27ec937.

The adapter now reads sessions from ~/.kiro/sessions/cli/ instead of the ~/.kiro/cli/sessions path that never existed, and it treats the per-session lock file as the running signal: a session counts as active only when its lock file parses and its PID belongs to a live Kiro process. Malformed locks are ignored, and a lock whose transcript is missing still surfaces the process rather than dropping it.

Tests cover the running-session mapping, the PID liveness check, malformed lock files, and the missing-transcript case.

Ready for another look when you have time.

[mvanhorn]

@codeaholicguy before I port this onto the current adapter layout (main has moved far enough that it is a re-implementation, not a rebase): is a Kiro CLI adapter still something you want in ai-devkit? If yes, I will redo it against main with the lock-file session discovery you pointed me at and keep the diff to the adapter plus its tests. If the answer is no, or it is on hold, I would rather close this than leave it conflicting in your queue.

[codeaholicguy]

@mvanhorn yes, if possible, please sync with the latest structure and update the PR, I will follow up after the PR is updated

[mvanhorn]

Synced. The branch is now rebuilt on current main rather than trailing it, so the diff is just the Kiro adapter against today's structure.

What changed in the port:

• Process discovery follows GrokCliAdapter now. The adapter declares processNames and resolves against the shared AgentDetectionContext snapshot when one is passed, falling back to captureProcessSnapshot only when called standalone, so the manager scans processes once per refresh instead of the adapter doing its own listing. node is in processNames because Kiro can run under it; canHandle still narrows on the kiro basename.
• Registered in the adapter index, the StartableAgentType union and the AGENTS registry, the CLI --type filters, and the docs.
• Formatting matches current main (oxfmt clean on the files this touches).

The Kiro suite is 12/12. Running the agent-manager suite before and after this change gives the same 224 pre-existing failures on main, with 13 more passing tests after, so this adds coverage without touching anything that was already red.

[codeaholicguy]

It reports non-Kiro Node processes as Kiro agents.

• The adapter watches every node process.
• isKiroExecutable then accepts a process if any word in its command line is kiro or kiro-cli, not just the program name.
• In the probe, all of these matched:
  • node /usr/local/bin/ai-devkit agent start --type kiro
  • node server.js --name kiro
  • kiro-cli chat
• So running ai-devkit agent start --type kiro (or any command with a kiro argument) makes a fake "Kiro process running" agent appear. agent send could then target the wrong process.

[codeaholicguy]

Each Kiro session runs as a chain of four processes. For example

55111 kiro-cli ← the adapter detects this one
└─55168 kiro-cli-chat chat
└─55198 bun … tui.js chat
└─55236 kiro-cli-chat acp ← the lock file holds this PID

The lock files:
9513a8c7-….lock {"pid":55236, …} → the acp process under 55111 (ttys007)
b511fa44-….lock {"pid":53216, …} → the acp process under 53123 (ttys001)

detectAgents needs the lock's PID to be one of the processes it collected. It only collects processes named kiro-cli, kiro or node, so kiro-cli-chat (55236, 53216) is never collected. Neither lock matches, and both kiro-cli processes fall through to the basic process-only agent: session ID pid- and no sessionFilePath.

The unit tests missed this because they write the lock with the same PID as the fake kiro-cli process. Real Kiro writes the PID of the acp process three levels down.

[codeaholicguy]

unrelated formatting change

[codeaholicguy]

@mvanhorn This has 1 blocker, after it is fixed then it good to go.

[mvanhorn]

Thanks @codeaholicguy, all three addressed in 92778b8.

1. Detection now only looks at the executable: kiro-cli/kiro, or for node/bun the script path. ai-devkit agent start --type kiro and node server.js --name kiro no longer register as Kiro.
2. The adapter also collects kiro-cli-chat and walks from the lock PID up the parent chain to the owning kiro-cli. When the chain breaks at the uncollected bun process, it falls back to the single Kiro process on the same tty. The tests now use the real four-process layout, with the lock holding the acp PID.
3. Reverted the HerdrAgentDiscovery formatting change.

Heads up: the two capacity rendering tests in packages/cli fail on this branch with or without this commit, so they're coming from the merged main changes, not from Kiro.

[codeaholicguy]

@mvanhorn please resolve all the conflict then it's good to go

[mvanhorn]

Merged main in (7525a2b) and resolved the conflicts. GrokCliAdapter now comes from the new providers/grok path, with the Kiro export next to it, and the channel test expects 7 adapters with Kiro registered. It's mergeable again, and the agent-manager and cli suites pass.

KiroAdapter still lives in adapters/ rather than providers/kiro/. Happy to move it over to match the new layout if you'd like.